Clash of the titans

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

Tags: , ,

5 Comments to “Clash of the titans”

  1. When PHP6 is coming, since they plan to add namespaces I would assume that all of the core php objects would be under no namespace while all of pear would be under a pear namespace.

    I think this would get rid of the issue largely at hand, while the current situation only helps create a passionate displeasure with pear.

  2. Taking a contrary view – PHP shouldn’t be registering classes internally until namespaces are available.

    For PHP4, the way to avoid namespace collisions with the built in API was to use classes – there were basically zero pre-registered classes in PHP4 then other than Dir and one or two in the Oracle extension. With PHP5+ packing more and more "preloaded" classes, that option is starting to look in danger.

    Otherwise, see nothing wrong with a class named "Date". What should it be called? Date_Time_Date ? Date_Date? What about PEAR DB?

  3. Mike:
    Yeah, namespaces will help if we get them, to me it seems a bit too much like speculations to be sure if they will actually implement them.

    Well if you look at both sides of the matter, all projects should always prefix their classes so that if they use 3rd party libraries then they have no class collisions and in turns PHP should be able to have it’s own internal classes with out having to prefix them for clearification reasons :)
    There’s nothing really wrong with the name Date, I for one would want everything in PEAR and all libraries to have the shortest class names possible but that yields for collisions and until we have the namespace then we have to prefix, regarding the naming … PEAR_Date or Date_Date (later would be following the PEAR naming schema, category_packagename kind of approach to protect the namespace)

    I guess same could be said about DB, that’s a bit generic name so PEAR_DB I guess, but like you pointed out, it’s because of how PHP 4 was designed that we have this mess, I doubt that no one ever thought that PHP would be putting in some internal classes like this, at least not in a “minor” version like 5.1.0, had it been in 5.0.0 then there could have been something done in PEAR but I haven’t been around for that long in the PEAR community :) At least not actively

  4. this topic is brainfuck! :) i don’t think there is a solution which will be nice for both sides.
    the blurred namespaces may solve this better anyday. until that day i think *both* sides should use prefixes strictly. "both" means php and professional userland environments. newbies, designers and idiots may use unprefixed classnames. whenever they do, their code will never break because all others use prefixes.
    regarding to namespaces or __autoload strict prefix convetions will have much advantages.
    my opinion ;)

  5. just read that post from rasmus:
    "It also sucks that not a single pear
    person tested the final RC and brought this up in the past week. There
    is plenty of blame to go around here."

    for that the next strict rule should be that every(*) pear package must have unit test. with every new php or pear release the complete pear
    repository tests should run.

    (*) ok some stuff is hard to test, so i’d say almost all

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: