Yeah, that’s about all this post will be. I read an article from IBM developerworks on the upcoming 5.3 features, and something got my dander up: closures.
I first got acquainted with closures in Groovy last year, and love them. They make sense. The syntax is pretty easy, and feels natural in the language. Not so in PHP. Once again, inconsistencies are not just legacy issues in PHP - they are created anew for us to deal with for years to come.
Look at the example here:
class Dog
{
private $_name;
protected $_color;
public function __construct($name, $color)
{
$this->_name = $name;
$this->_color = $color;
}
public function greet($greeting)
{
return function() use ($greeting) {
echo "$greeting, I am a {$this->_color} dog named
{$this->_name}.";
};
}
}
Given that ‘anonymous function’ inside the greet() method is a closure, WHY NOT NAME IT THAT? The PHP Reflection API was updated to include a “getClosures()” method, but what would you get? They keyword “closure” doesn’t exist, but could have. Instead we now have the keyword “function” looking like two different entities - it looks like a
function call when used with the () directly after it, and also has its traditional function fname() syntax still available.
I have to teach this stuff, and being explicit with a closure keyword would have saved a lot of headaches to come in explaining this stuff to people. Additionally, it would have been less to type.
Compare
return function() use ($greeting) {
echo "$greeting, I am a {$this->_color} dog named {$this->_name}.";
};
with
return closure($greeting) {
echo "$greeting, I am a {$this->_color} dog named {$this->_name}.";
};
What’s more explicit, easier to understand, and fewer characters to type? Given the recent namespace separator debacle (using \ as a namespace separator, and justifying it because it’s “fewer characters to type”), I can’t really understand the rationale behind the closure syntax.
To be fair, the closure syntax RFC was up at http://wiki.php.net/rfc/closures and I didn’t comment in time. So, I guess it’s all my fault. 
Beauty and elegance have never been PHP’s strong suit, but it seems people went out of their
way to make this unintuitive and bulkier than it needed to be. :/
On a more broad note, I really think the bulk of these changes (closures, namespaces, etc.) should have been put in php6 only, not in the 5.3 series. I understand the need for testing and such, but we’re implementing new functionality and defining how it is expected to work based on the current PHP5 Zend Engine. Whatever useful
changes that might make a PHP6 faster/better/whatever can’t easily be implemented because the ‘new’ features are all dependent on a core engine that’s already 5 years old, which it itself was built with an eye towards backwards compatibility to PHP3. Strategically, it just feels like the wrong move. But hey, what do I know,
right? I can’t write C code patches, so my views don’t really have much weight, do they?
