Me griping about PHP :) (closures this time)

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

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.


return function() use ($greeting) {
 echo "$greeting, I am a {$this->_color} dog named {$this->_name}.";


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 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?

I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Web Developer Freelancing Handbook

Share and Enjoy:
  • DZone
  • Facebook
  • Reddit
  • StumbleUpon
  • Digg
  • Simpy
  • Technorati


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">