Monday, December 21, 2009

The Advent that became Tribulation

There is a nice initiative in the php community whose goal is to put together a set of best practices for php programmers and to having them explained every day of December from experienced developers: the PHP Advent.
However, this year I have been disappointed by the quality of the articles in the advent. First, there is no Add Comment form. What? What advent is this, 1995's one? Are the articles stored as static html files? I remember there were definitely comments in 2007.
After having asked the reason on Twitter, I got this response:
@giorgiosironi we've considered adding it, but like the idea of crosslinking with our authors' blogs when they create an entry. /cc @chwenz
The problem is that there is no duplicate post on the author's blog, at least for the majority of them. The only place where leaving a comment makes sense is on the original article, which admits no feedback.
Now we can start to list what I, and probably many other developers, would have commented on some of the articles.

December 8: Testing with PHPT and xUnit
The author suggests to abandon the standard testing framework for php, PHPUnit, to use PHPT, the testing harness for the php core itself.
PHPT has a very simple plain text interface where you specify text files containing the code to execute and its expected output. Not as variables - as text output, usually of var_dump(). This tool is used to testing php itself because using a real framework with more features, like PHPUnit, means that it will probably break while running the test suite if a regression is introduced in php.
Then what are the reasons to dismiss PHPUnit if you are not developing the php interpreter? The author say "with PHPT you can test for expected fatal errors!". Why I would want an expected fatal error in my application? With a nice blank page shown to the end user? I can't even think of renouncing to PHPUnit.

December 12: JSON Gotchas
Towards the end of the article, the author says something like: You know what is really cool? Passing an anonymous function in a Json string.
var jsonString = "({name: 'value', toString: function() { return; }})";
What's the problem? That this is not Json, it's plain javascript syntax... says a value is string|number|object|array|true|false|null and an object is something which is enclosed in {}. Do you see anonymous functions in this specification?
This Json string would probably work if passed to eval(), but not to secure Json parsers. The author recognizes that you cannot avoid eval() in this case, but it's not a mystery why: because it's not Json anymore, and calling it Json causes confusion, much like $array = new stdClass(); and other obfuscated code.

December 18: You Don't Need All That
Classes are slow! MVC is even slower! Real men do not use autoloading! We should stick to require_once(). The best part?
Or, put some effort into writing more general, commonly-used classes rather than lots of little ones.
Never, ever, heard of Single Responsibility Principle? Cohesion? Decoupling? That design should not be driven by how fast including source files will be? I actually refactor every class that surpasses 400-500 lines of code.
If you're thinking to follow the advice of discarding autoloading, maybe you'd like to know that PEAR 2 will drop require_once() statements. As for the post, if you do not believe me as a source of information, Roman Borschel, the lead developer of Doctrine 2, says:
@giorgiosironi agreed. complete crap. Another meaningless artificial benchmark. Not even with repro code. that post is a big #fail.
There are very valid posts in this year's PHP Advent, but these hidden "gems" are dangerous and I wonder why no feedback is accepted. Open discussion would benefit the community more than lectures on php practices.


romanb said...

The problem with the day 18 require stuff is that it is an artificial, unrealistic situation.

The real problems with hard require statements can be seen in libraries like Zend Framework. How do you do it? In a first, naive try you require() all dependencies of a class explicitly at the top of a class file. This quickly leads to "cannot redeclare class" errors because many classes have the same dependencies. Now you make it require_once, which is even slower. Now that works but you end up with multiple require_once calls for a single class file.

Of course you can not require anything in your class library and push it all on the user to require all the classes he wants to use. Poor users.

Additionally, to avoid always require() exception classes that are not used most of the time you end up with constructs like:

if (blablabla) {
// oops, error
require_once 'Blabla\Exception.php'
throw new Blabla_Exception

Couldnt be any more cumbersome.

These are also the main reasons for ZF completely moving away from hardcoded require stuff afaik.

And really, providing downloadable source code with instructions on how to reproduce the test is the least that is required for a benchmark to be taken seriously, no?. (Or did I just not see it? If so, I'm sorry.)

Giorgio said...

I cannot find downloadable code too.
Pear is abandoning require_once() also to avoid the assumption that classes are in a disk folders: they may be kept in a phar archive or wherever. Since 2010 is coming I thought that there were no more autoload-atheists.

James Dempster said...

I was thinking the same. It's such a shame.

Maybe now is the time to start thinking about what we can put in next years. Then maybe it wont be so bad.

rogeriopvl said...

I would like to now what you think about the day 20 post. When I read it, I though it was a joke... I still hope it is, because it's so wrong in many ways...

James Dempster said...

I'm pretty sure that's a joke, tongue in cheek (Unmaintainable PHP).

It's something I have wondered before though. Doing your job so well that the code doesn't even really need maintaining.

Giorgio said...

Day 20 (Unmaintainable Php) surely is a joke. Actually, an old joke:

Anonymous said...

What's Happening i'm new on here, I stumbled upon this forum I have found It vastly accessible and it's helped me out so much. I hope to contribute and assist other users like it has helped me.

Thanks Everyone, See Ya About.