Code works, the unit test fails...

In this case it turned out to be simple: the test failed because it was making wrong assumptions after a code change. But I never got to know, as PHPUnit ran out of memory... This is the end of the XDebug trace:
 42.4811  96481024 -6824    -> PHPUnit_Framework_Constraint_IsEqual->fail(class F3\Fluid\Core\Parser\SyntaxTree\RootNode, string(36), ???)
42.4812 96481136 +112 -> PHPUnit_Framework_Constraint->failureDescription(class F3\Fluid\Core\Parser\SyntaxTree\RootNode, string(36), bool)
42.4812 96481216 +80 -> PHPUnit_Framework_Constraint->customFailureDescription(class F3\Fluid\Core\Parser\SyntaxTree\RootNode, string(36), bool)
42.4812 96481440 +224 -> PHPUnit_Util_Type::toString(class F3\Fluid\Core\Parser\SyntaxTree\RootNode, ???)
42.4813 96481616 +176 -> is_array(class F3\Fluid\Core\Parser\SyntaxTree\RootNode)
42.4813 96481696 +80 -> is_object(class F3\Fluid\Core\Parser\SyntaxTree\RootNode)
42.4813 96481832 +136 -> print_r(class F3\Fluid\Core\Parser\SyntaxTree\RootNode, bool)
51.5357 441897744
TRACE END [2009-11-21 09:59:22]
Note print_r line? The second field is the memory used. PHPUnit trying to get a diff of that turns out is too much. Well, around 450 MByte of variable dump - I cannot blame anyone. :)


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!