Pondering PHP 6

Let me start off by openly admitting that in no uncertain terms am I speaking on this topic with any substantial amount of authority. I don’t subscribe to the PHP internals list and the gist of what I’ve heard about it indicates that the most likely result would be subsequent nightmares for life. (OK, maybe that was melodramatic, but you get my point.) The last time I dealt with C or C++ was a semester or two before finishing out my bachelor’s degree. That was during a time when the compilers course being taught at the university I attended became optional within our curriculum, and to ease the workload of my schedule, I skipped it. I rather regret doing so now, and while I’ve always meant to set aside time to inspect the innards of PHP and make a contribution myself, it’s always sat on the ever-growing laundry list.

Be that as it may, as a user with about five years under his belt as of now who has seen all qualities of PHP code ranging from pristine to pedantic, a thought or two has crossed my mind on the subject of the latest upcoming incarnation of the language. I know, I know, everyone and his brother has already spoken on one aspect or another of the subject. This is just my two cents; take it for whatever it might happen to be worth to you.

Namespaces – While this was an on-the-fence topic and debated for some time, I’m personally glad to see the addition. The common practice in lieu of this feature has been to fully qualify class names with what would normally be the namespace, which leaves them rather long and painful to look at. David Coalier has started a series on namespaces to further explain them.

mysqlnd driver – It saves memory, passes more unit tests, provides tighter integration with PHP, and otherwise lands a pretty good sucker punch against the existing libmysql-based driver. Despite the licensing snafu that generated a decent deal of hype many moons ago and was eventually handled with the FLOSS License Exception, I think it’s fairly safe to say that MySQL is the database most commonly used in conjunction with PHP and this is going to be an awesome improvement.

Unicode support – OK, I know a lot of effort has gone into implementing this, a lot of people are drooling over it, and I can certainly appreciate that. As for me personally, aside from the capability of a few neat tricks that have more of a coolness factor than a usefulness factor, this doesn’t really have me jumping up and down. I’ve never had to work on sites where localization or internalization was needed to the extent that non-Latin character sets had to be used.

Deprecations – Go register_globals! And take register_long_arrays, magic_quotes_gpc, and safe_mode with you! These settings have contributed to the ability of implementing messy code for far too long. My only gripe is, why is open_basedir not also on the way out? It may not cause any issues in PHP itself, but doesn’t its mere presence imply that it should be secure when the PHP 6 meeting notes admit otherwise?

Named parameters – The meeting notes have an example of what these are and detail the reasoning behind why they’re not going in, which I can’t say I agree with. I’ve never heard of PHP purporting to follow the KISS principle in any respect. What exactly is the “it?” I wouldn’t say there’s anything easy or clean about the current common practice, which is to use associative arrays. Personally, I think it’s ugly. This may be syntactic sugar, but it would make code look a lot more readable.

There are many other significant changes in PHP 6, but those are the points that drew the most attention from yours truly. Regardless, PHP 6 seems to be major improvement over past iterations and I hope it overcomes the adoption difficulties that PHP 5 has experienced.

One Comment

  1. harald says:

    i totally agree to you regarding “named parameters.” i’ve learned to love them when using perl – it’s always a problem when you have a method with more than one optional parameter.

    i can’t follow their argumentation on messier code because on the other hand they implement labeled breaks, which in my opinion is really totally useless (at least i never missed them in my seven years of php programming experience) and really makes messier code if used a lot.

    on the other hand named parameters would help make the code more readable without having to look in the API documentation if you read other ones code.

    so i’m not sure if the argumentation in the meeting notes is really what they think about this feature or if there are other – political – reasons not to implement named parameters.

    it reminds a bit on the discussion about namespaces. suddenly someone committed a working patch, and the discussions about whether to implement or not to implement namespaces were gone.

    thanks again for your article.