Namespaces are potentially coming in PHP 5.3 (does anyone believe?) and people start discussion about how they can even shorten their names from Abstract to aSomething and from Interface to iAnotherthing. I'm a fan of short names. [...] I agree with these rules and am of the opinion that class names must all above anything contain a semantic. Interfaces indicate what you can do with an object, while abstract classes model that different classes have a common base and can be used in the same mannor. And indeed you can add these semantics to names without using the terms.

He gives a few examples, things like Persistable, Configurable and Reflector.

One of the things that came up is the conflicts that can arise with internal classes. In PHP 5.3 this would alias the class Interval in the namespace PEAR::Date to the class Interval. For now, this code would work just fine. However, if PHP would introduce a class "Interval" at some point in the future (and PHP can do this as it owns the global namespace) then the above code would suddenly stop working

He offers a simple solution that can prevent this sort of conflict for the future - defining your "use" and then creating a new instance of the namespace into a variable instead of just an "as".

After investigating (which in my case meant briefly recalling from memory how PEAR actually validates dependencies), I remembered that PEAR validates dependencies twice, once prior to download, and once prior to installation. By the time the dependencies are sorted, PEAR assumes that the sort algorithm properly sorts things.

This is actually a pretty reasonable assumption considering the unit tests that are in place to test this. However, like all regression testing, the unit tests test boundaries and likely cases, but not all possible inputs.

So, to try to figure out where things might have gone wrong, Greg does a little research to find the problem. He discovers that it has to do with the order that the "subpackages" for the dependencies are installed, where the contents of those files are not removed correctly before installation, resulting in a file conflict.

The MySQL binaries found on mysql.com are built against yaSSL as opposed to the more common openssl against which libcurl (usede by cURL and HTTP extensions) is linked. The conflict between the two libraries causes curl initialization of the SSL layer to fail preventing startup of the PHP extensions.

The fix? To either use the older mysqlclient libraries or manually compile MySQL yourself against the OpenSSL libraries.