PHP Standards Working Group - what's the point?


Recently Robert Lemke joined the PHP Standards Working Group as a representative for TYPO3. Since we are working on the FLOW3 framework as a by-product of our complete TYPO3 rewrite, we are of course interested in interoperability and standards to ease our lives.

The group is currently discussing a first proposal on "autoloader interoperability". While the proposal is short and makes a lot of sense, it deals with a little technical detail that I think is less important to interoperability than other issues: class autoloading. While a common scheme for namespace usage helps avoid name clashes and makes programming less guessing and more knowing (and as such is a very good thing!), having a standard that de facto forces a single autoloader implementation (let's face it, a sample in a standard is prone to become a fact due to laziness...) might get into people's way.

I would be happy accepting the code changes needed to comply with the standard's notion of a namespace beginning with a "vendor name". But moving all of our code out of our Classes folder we have in packages used within FLOW3? The separation between code, documentation, resources and metadata in those packages is too precious.

Thus I would be happy if the proposal focused on a common scheme for namespaces only and left an autoloader implementation out of the picture. Maybe suggest a common name for a vendor-specific autoloader so you know where to find it. Because, let's face it, adding another autoloader is the least of your problems when integrating a library.

Which brings us to the more important issues the group should look into in the future: How to foster technical interoperability in the sense of component decoupling, reliance on certain PHP settings (I'm sure most of you ran into some sort of magic_quotes_gpc issue in the past) and so forth.

Anyway, having the most prominent (framework) projects inside that standards group is already something worth celebrating! Keep the ball rolling!


Leave a reply

Karsten Dambekalns

Creative Code Engineer

Contact / Impressum