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."

Comments

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, 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 , magic_quotes and safe_mode 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: 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 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

Do most users even need PHP 6?

[CRCulver]

I wonder if most of the new features in PHP 6 will even appeal to most users. I started on PHP 4 with O'Reilly's Programming PHP and when PHP 5 came along, I didn't notice anything that was really missing. It's like Perl 6, there are already plenty of people who feel that what they have so far serves their needs, and there's not anything to improve upon.

Re:Do most users even need PHP 6?

[masklinn]

Try some other languages (Ruby, Python, CLisp/Scheme/Haskell/OCaml if you manage to get past the syntax), you'll see that PHP is lacking in many areas.

Closures (even read-only, as in Python), functions as first-class objects, namespaces, modules, consistency across the standard library, properties, metaobjects, strong typing (not static, strong), infinite-length integers (these dummies want to add a 64bits integer in PHP6... whoa, so kewl eh), good iterators (not Java's, either Ruby style or Python style iteration), partial application (curryfication), pattern matching, ...

Re:Do most users even need PHP 6?

[self assembled struc]

I think you're missing his point.

In my experience (working in large PHP driven shops) the people writing PHP didn't necessarily have a comp sci background. They don't care (and most don't even know) wahat a first-class object is, why they would even want namespaces, strong typing or 64 integers. In fact, adding them to the language makes it in accessible to them, so they'll just stick with php 4, which "works for me."

I mean, in a fundamental sort of way, yes PHP is broken, but in a useable sort of scripting language way, PHP 4 isn't broken. And if it ain't broke, then don't try to fix it.

Namespace

[CHaN_316]

It'd be great if variables, functions, classes, and constants could be defined in their own namespaces. For really big projects, it's too easy for names to collide in the global namespace. An annoying workaround has always been to make names unique by prepending them with something.

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. 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.

Lack of backwards compatibility

[kestasjk]

phpBB, vBulletin, mysqladmin, postnuke, phpDiplomacy (shameless self promotion), etc, etc; 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.

They should leave in backwards compatibility for the class based OO model which <PHP5 uses. Once they bring out PHP6, PHP5 will be the only version which runs new and legacy PHP scripts, so PHP5 will clearly become the standard for a long time.

I'm a big fan of PHP, but with so many apps (e.g. my university's timetabling app) still in PHP3, all the rest in PHP4, both becoming obsolete, changes to the API, even changes to what's allowed within the same version; I'm starting to wonder if I should have focused on a more stable language like python or perl instead.

PHP needs serious redesigns

[tehshen]

No, seriously. PHP has accumulated a lot of broken things over the years, and it is hurting it. This new version of PHP should be turned into a whole new language entirely, or made incompatible with older versions (like Perl 6 is doing). Reasons:

PHP's design is fucked up. Some functions have underscores, others don't; some have numbers, others don't: strtolower, isset, stripslashes compared with hex2bin, is_null and strip_tags to name a few. Why? Who knows? But too many applications rely on these inconsistencies, and making them consistent would break everything.

It has no namespaces. Luckily, they are to be added in PHP 6 (and about time too!), so we can do $db::connect() rather than mysql_connect($db). So can we get rid of all the mysql_* and other pseudo-namespace functions please? They are annoying and will be wholly unnecessary.

Security problems. Register_globals and magic_quotes are still built into PHP when they should be built out and as far away from it as possible (and they are!). There are going to be people who will wonder why this upgrade breaks those things, and people should know that a new language does things differently. (Likewise: Perl 6's given/when block isn't called switch/case because it behaves differently).

Now that I've typed all that, much of my reasoning is that people rely on PHP's being bad. People should never rely on poor language design, or bugs, or bloat, of which PHP has loads. The language should work, you shouldn't need to work around the language - and if you do, you're going to have a lot of trouble rewriting your code.

There might be little incentive to switch away from older versions of PHP for some people, but a few refinements of the language won't change that. "Better than PHP" would actually be true. "Made from the PHP team" would be a major selling point too.

I know that it's a bit risky saying this here (there seem to be a lot of people who like PHP for some reason), but a serious redesign is in order, and it's more than just a simple bumping up of the version number can fix.

Re:How about "use strict;" directive

[MavEtJu]

Too true. Declaration of variables, and local variables in blocks, is what keeps preventing me from making stupid mistakes in Perl.

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.