PHP 5.1.1 Released!

The initial and probably the main reason for the PHP 5.1.1 release in such a hurry was a rather interesting problem. One of the features introduced by 5.1.0 was the addition of the native “date” class. This was done for two reasons, to allow date extension’s constants to be namespaces to the class, which makes accessing them far faster and does not pollute the global class space. The other reason was to reserve the “date” class name, to indicate that applications/libraries should not implement it themselves. The eventual plan was to enable additional ext/date functionality via this class through a series of methods that have already been written. With these seemingly reasonable goals in mind after discussing the issue with Derick Rethans (author of ext/date), I’ve applied the patch to this affect in 5.1.0RC6, with the assumption that this would not break anything. This assumption held true for an entire week leading up to the final release. Even the upgrading guide (meticulously written by Steph Fox), mentioning this feature and discussed on both IRC and internals mailing list failed to provoke any kind of reaction from either the pear::date users or the developers.

The real “fun” began a couple of hours after the release when Pierre-Alain Joye posted a message titled “PHP 5.1 (Or How to break tousands of apps out there)”, whose title was certain to provoke a reaction and boy, did it ever. Within a few hours just about every frequent responder to the internals mailing list had their say. As per usual most of the traffic was something to the affect of: I don’t like it, I don’t like because developer I usually agree with does not like it, I don’t like it because I feel like being contrary, etc… A number people did make a few suggestions (those of you who did, you have my thanks), but the discussion was quickly returned to complaining, counter-complaining, and so on. If you have a few hours to kill and enjoy seeing developers bicker, here is the full thread: http://beeblex.com/lists/index.php/php.internals/20324?s=l:php.internals

While internals mailing list was engaged in an e-mail version of world war 3, the PHP bug system at http://bugs.php.net was surprisingly quiet. When something important is broken, in a near instant we have dozens of reports on the topic. In fact, only a single bug about this issue was posted and within a few minutes bogused by the user himself, who took the time to read the upgrading guide and saw the note about the date class stab. That was all, there were no further bug reports or complains on the issue in the 4 days that the 5.1.0 release was out in the wild. The only way I feel this was possible is that if the date usage statistics were greatly inflated thanks to automated downloads and do not accurately represent the number of users using it.

At this point as the 5.1 Release Master I had a few options, ignore the issue, citing the upgrade guide, non-existent bug reports, etc… Rename the date class to avoid the namespace conflict or remove it all together.

At first I was very much against doing anything, because changing the core class to be compatible with PEAR seems like an exceptionally bad decision. I, as number of other developers feel that the 1st choice of the namespace for functions & classes should be given to the programming (scripting in this case) language rather then code written in it. By allowing PEAR or any other PHP library dictate naming conventions for the language we prevent the language from choosing names that have the least amount of WTF factor. It seems very shortsighted to have a native date class called PHP_DATE or alike, so that an optional PEAR library can make use of “date” for its class name. Unfortunately this was seemingly the minority opinion and fixing the problem in PEAR didn’t get much traction, despite PEAR’s own naming conventions saying that all classes should have a prefix, oh well. The majority seemed to be focused on fixing the “problem” in PHP and would not be swayed. My first solution was to offer to rename the class, in attempt to retain the functionality (class constants), in retrospect it was a bad idea and I am glad it was not accepted. Interestingly enough by the time it was offered, the original thread had since long abandoned the “date” discussion and moved onto more interesting things, namespaces, which are still being discussed in that thread. I guess talking about dates; can only hold people’s attention for so long. After some discussions via e-mail and IRC the decision was made to remove the class by putting it inside #ifdef, and leave the date discussion to a future point.

So, what can we learn from this? First it seems that when it comes to PHP, given a sufficiently loud minority or reasonably vocal majority it is possible to force the language design to work around the applications written in it. PEAR developers are free to ignore their very own standards, not test their code against Release Candidates designed explicitly for that purpose and then look surprised and complain when things break. This is not the first time nor the last the release process has been given a bitter pill thanks to PEAR. Just today, few hours after 5.1.1 was released, Greg Beaver informed me that Win32 phar files were broken and our Win32 build master, Edin Kadribasic had to do a last minute repack.

Are there any solutions? Once possible step would be for the PEAR’s leadership (pear group) to reign in the development forcing adherence to their standards and work on addressing namespace takeovers by existing classes. Another would be to ignore the issue and wait for the appearance of namespaces in PHP 6 and hope that they magically solve the problem. Finally, PEAR 2 can be launched aimed at rewriting PEAR from scratch utilizing 5.1+ functionality resulting in a much cleaner and faster code.

Equally importantly is to have PEAR project find the time to communicate with RM during the release cycle and notify us ahead of time of any problems. Had this been done, the entire 5.1.0 fiasco could've been avoided.