PHP 6 and What to Expect

An anonymous reader writes "Jero has a few interesting thoughts on what PHP 6 is driving towards and provides a nice overview of what has been keeping the PHP team busy lately. For more specifics, PHP.net also has the developers meeting minutes from last November available with a great recap of all the major issues on their platter."

Article

[perlionex]

Since jero.net already seems to be /.ed...

Taking a look at PHP 6

While most web hosts are still in the PHP 4 era, the PHP developers are already planning and working on PHP 6. Lets have a look at whats been keeping them busy.

Unicode support

When youre creating a website, you hardly have to think about the character encoding. You only have to decide how you tell the user agent what encoding youre using, but with a little help of Apaches .htaccess file [slashdot.org], you only have to make that decision once. However, if youre building an application, the character encoding might become a problem. Thats where PHPs new Unicode support comes in handy. With its support, PHP can automatically encode and decode the in and output of the script making sure both the database and the user agent receive the encoding they need without the need of any extra functions for the encoding conversion.

The big cleanup

PHP is already being used for a long time, creating a big user base, but also a lot of bad habits. Bad habits often result in slow scripts or even security holes. But these bad habits are not always the cause of the developer. Of course, he (lets just assume were dealing with a stereotype developer here for simplicity's sake) is the one whos using it in his application, but sometimes the developer is not even aware hes using it.

Im, of course, talking about the register_globals [php.net], magic_quotes [php.net] and safe_mode [php.net] functions. These three functions are hell for every PHP programmer so Im sure everyone will be happy to hear that these functions will disappear in PHP 6.

In other related cleanup news, register_long_arrays and the long versions of the super globals like $HTTP_COOKIE_VARS are also gone in PHP 6. Same goes for zend.ze1_compatibility_mode which dealt with the backwards compatibility of PHP 5 classes.

Alternative PHP Cache

Caching is a very good way to improve the performance of an application. Thats why there was a large demand for a good opcode cache in the default distribution of PHP. And when theres a demand, theres probably also a person or a group to meet that demand. The result is APC [php.net]: Alternative PHP Cache. Of course, APC was already available a long time ago (01-07-2003), but the PHP developers have decided to include this extension in the core as the default caching framework.

OO Functionality

The improved OO model was probably the biggest improvement to PHP in version 5.0. PHP 6 tries to improve this even further by adding namespaces. If youre familiar with XMLs namespaces or maybe C++, you will probably have an idea of how namespaces work. If not: Namespaces can group variables, functions or objects under a certain name. This allows the developer to use the same name for a variable, function or object multiple times. In case youd like to learn more about the possibilities of namespaces, I find this C++ tutorial [cplusplus.com] about namespaces quite useful.

Changes to the extensions

PHP is basically a collection of extensions which are all put together to form what we have now. However, these extensions change and so does the collection. Take, for instance, the XML Writer extension. A great extension to write XML files. Its brother, XML Reader, was already added and enabled in the core distribution in PHP 5.1, and now XML Writer will follow its example in PHP 6, forming a great duo to easily work with XML files.

Another change in the core distribution is the removal of the ereg regular expressions library which is going to be made an extension. ereg is currently used

Re:Namespace

[iangoldby]

From the article:

The improved OO model was probably the biggest improvement to PHP in version 5.0. PHP 6 tries to improve this even further by adding namespaces.

Will this do?

Re:the license

[kuzb]

There isn't really anything to hate about the PHP license [php.net]. It's free to use for business or personal use, and it's distributed in source form so you can poke at the internals. You're allowed to modify it and even redistribute it. I don't see what the problem is here. You're whining about nothing, I suggest you find some cheese to go with it.

Re:Lack of backwards compatibility

[NeoThermic]

>phpBB[...]; none will work until they've been ported to the new PHP5 OO model, and once they've been ported they won't work on PHP4.

I'll note that phpBB 2.0.x was written for PHP3 and PHP4 (those were the only target versions of PHP about when 2.0.0 was released). The fact that 2.0.x works with PHP5 is proof that there's enough backwards compatability with PHP4. The bits that break are proof that there's not enough ;)

Also, phpBB 3.0 is being wirtten for PHP4 and PHP5, of which it works fine under both right now (although its still in CVS). We did a quick test last week, a CVS build of PHP6 shows no immediate problems with phpBB 3.0 - obviously when it hits beta, this will be tested properly.

Having delt with lots of support requests, I do note that the split of PHP4 to PHP5 is about 95 to 5 percent. As far as I see it, unless PHP does something drastic like dropping all future support of PHP4, I doubt the uptake of PHP5 will get anywhere decent.

I will agree though, the PHP language needs to stay stable. The "by reference" change between PHP 5.0.x and PHP 5.1.x is a great example of something that should of been left for PHP6..

NeoThermic

PHP's biggest problem

[rnd()]

Nobody has pointed out the biggest problem with PHP5, and it doesn't appear to be addressed in PHP6: Exception handling.

PHP5 came with exception handling like that found in most mature object oriented languages, but the problem is that most PHP functions do not use exceptions, they simply return false.

This makes it difficult to use exception handling at all, because you have to mix the old way and the new way if you want to leverage PHP's huge library of functions.

I think the solution would be to implement standard exception behavior for all of the old libraries and add a setting in php.ini to turn the behavior on or off.

It's easy to write a PHP script that will fail without throwing an exception or returning a boolean value that can be handled. This makes PHP very difficult to use if you need your code to be very robust and solid. I've resorted to using classes and putting some code in the destructor to clean up if the script terminates unexpectedly, but this is ugly and should be something that one can handle by enclosing the error-prone logic in a try/catch block.

Needless to say, this problem isn't always a major issue for websites, but if you're doing anything more complicated than simple db lookups and printing HTML, robustness matters and PHP's shortcomings really stand out.

Partially due to this problem I recently switched a fairly large project to Ruby on Rails and have been EXTREMELY pleased with how fast development has progressed. I was able to reproduce 2 months of PHP development in rails in 2 weeks, learning curve included. Ruby is a joy to program with, way easier than PHP, C#, Python, etc.

Re:PHP's biggest problem

[miyako]

Actually, they mentioned this in the article. It was decided that they would not use exceptions for built in functions, because they couldn't decide where to draw the line between throwing an exception and halting the interpreter.
I agree that it would be a nice option to have, though in my experience the only language I've worked with on any regular basis where people actually use try/catch blocks instead of the return false way is in Java, which requires it.