As many have noticed 5.1.0 had some issue when it was released, like for starters it introduced a empty date class by default which effectively killed scripts that used PEAR::Date (I admit, it’s rather silly to give a pear package such generic name) or any other scripts that uses a class called Date, which I imagine are quite a lot since it’s seems rather convenient to pick the shortest name possible and many people look passed the fact that they need to prefix their classes.
As one can see in this excellent rant by Ilia located at http://ilia.ws/archives/95-PHP-5.1.1-Released!.html there are different views on how this should have been handled (also read the internals ML if you need even more reading material), namely why PEAR was polluting generic names and why they didn’t fix it right away so PHP could get the glorious name of Date, this debate actually makes me think back to when Marcus introduced a SPL class called File which obviously conflicted with the PEAR::File class (and probably other classes that are out there) but again PEAR got to keep the name and SPL::File was renamed to SPL::FileObject so that everyone (except Marcus ? :-P) could be happy and everything worked smoothly in the 5.x series.
Now in my opinion PHP should in fact get these class name, just not in 5.x instead we should use PHP 6 for that, that is we should deprecate those packages and / or see to it via package.xml that they can’t be installed to PHP 6 installation, and thus the core Date class can live happily and also FileObject could be named to File as it is the “rightful” owner of that name.
So that I revisit Ilia’s rant for a moment then Sean, Pierre and Aaron gave good comments as to why PEAR can’t just jump on the bandwagon and change names on their classes out of the blue if the package in question is stable, so I’m not going to repeat what they said but instead I’m going to address another thing Ilia said with out anyone commenting on it, and that’s the prefixing issue.
So why did Date, File and those not have prefixes when our very own coding standard says they should ? Well, as anyone can see then we are talking about prefixing the category of the package in front of the package name, like Validate_IS, Crypt_Blowfish, Services_Webservice, Services_Amazon and so on. This standard was put in place because of the very reason that has been happening lately, so that packages won’t collied in names nor that they will collied with any other class, like say a core PHP class, but that hasn’t answered why Date and File don’t have prefixes but the answer is very very simple, both of those packages are over 3 and a half years old, which by my count is way older than most of those CS rules and unfortunately we can’t enforce such prefixes on a stable thing and thus break backwards compatibility, this is life and we have to deal with it and I hope we do that in when PHP 6 comes along.
A short note tho, in some cases it’s just extra obfuscation to put some prefixes on class names, like in the case of MDB2, LiveUser, PHPDocumentor and FSM just to name few that IMHO should not be put under the prefix burden because of their rather unique names but hey there’s 100% someone that disagrees with me on that :) But I do think that PEAR should be a bit more careful in this regard so that we don’t be the wrath of the internal people on them even tho it’s funny to see those things evolve at times, specially when they backfire or the internals people just talk in circles ;)
But all in all, if anyone actually stayed awake long enough to get way down here, then this is just my little personal take on this whole situation and as to how I want to see it resolved.
Helgi Þormar Þorbjörnsson 