

Closure Object Binding in PHP 5.4 - yuri41
http://christophh.net/2011/10/26/closure-object-binding-in-php-54/

======
Udo
It's definitely nice that closures are real objects, but I don't see the
justification for the bindTo() method. Take this, for example (from the
article):

    
    
      $app->get('/', function() use ($app) {
        $request = $app['request']; 
        });
    

The _use_ keyword is good for importing anything from the current context into
the closure. However, I'm not sure it's a good idea in this case because it
seems unnecessary - which makes the example a bit of a straw man: The $app
object already knows about itself, so why not do the simpler and more loosely
bound version:

    
    
      $app->get('/', function($app) {
        $request = $app['request'];
        });
    

then when calling the closure, the object just has to do this:

    
    
      $closure($this);
    

That way you don't have to remember to "use ($app)" every time you define a
closure (and I'm also not wild about overlapping variable names from different
contexts).

Now we have the new bindTo() method which results in yet more extra code:

    
    
      $boundClosure = $closure->bindTo($context);
    

Granted, you could define a general bindTo mechanism once per class
implementation, and being able to use $this inside the closure is nice, but
I'm not sure this justifies an addition to the language's complexity when a
perfectly fine method has been around that does the same thing (and with less
code).

~~~
maratd
> but I don't see the justification for the bindTo() method.

The new array syntax, closures, binding ... I'm surprised you're not seeing
the pattern. All of these features are borrowed from JavaScript. Absolutely
fine by me. I already spend most of my time in JavaScript anyway. I'm willing
to bet I'm not alone, hence the changes.

~~~
Udo
So it's desirable to eventually converge PHP and JavaScript? You're right: I
don't get it. Why then have PHP at all? I'm not saying that retrofitting a
language is a bad idea per se, I just don't see the appeal of doing it when
there was a perfectly fine alternative to begin with. The new array syntax is
great, and introducing closures was way overdue, but this one..?

Oh well, it's in there now, so I guess there is no point of discussing it. But
I do believe, on a more general note, that saying "no" to features is
important - and bindTo() would have been an excellent point to say no to. For
better or worse, PHP is not JavaScript and vice versa. Their paradigms are not
really compatible to begin with. Transplanting stuff from one to the other
just because it saves 7 bytes in developers' brains is not enough of a reason
to do that in my opinion.

~~~
maratd
> So it's desirable to eventually converge PHP and JavaScript?

PHP has always been about making coding easy and fun. Since more people are
doing JavaScript, it only makes sense to make things familiar.

> Why then have PHP at all?

That's a question that will have to be answered soon.

For now, the answer that I'm coming up with, is that with PHP-FPM you can make
PHP properly threaded. All of the server-side JavaScript implementations are
event driven. The threaded model has advantages when jobs are cpu or io heavy.

Right now, I'm working on an implementation where Node.js is receiving calls
via websockets and handing that off to PHP-FPM via FastCGI for processing. A
hybrid system like that has advantages of both the event model and the thread
model.

~~~
Udo
> _Right now, I'm working on an implementation where Node.js is receiving
> calls via websockets and handing that off to PHP-FPM via FastCGI for
> processing. A hybrid system like that has advantages of both the event model
> and the thread model._ <

That sounds pretty cool. Personally, I was blown away what difference
Nginx<->PHP-FPM makes compared to the old Apache way of doing things. Nginx is
an absurdly fast evented web server as well. It would be very interesting to
bring this kind of thing to Node.js because it would allow for some awesome
customization which just isn't possible with Nginx.

------
mgkimsal
Would have preferred something to enable more visually pleasing
metaprogramming, like:

$closure = function() {

echo $this->foo;

};

$context = new \StdClass;

$context->foo = "Hello World";

$context->closure = $closure;

$context->closure();

Not sure if this will be possible in 5.4, but haven't seen anything on it.
Right now, we have to do

$context->closure = $closure;

$temp = $context->closure;

$temp();

which is kinda ugly.

~~~
deweller
You can use this:

    
    
        call_user_func($context->closure);
    

But yeah, some syntactic sugar would sure be nice. I'd like to see this in a
future version of PHP...

    
    
       ($context->closure)();

~~~
mgkimsal
It doesn't even have to be 'sugar' like that.

$content->closure()

It could look at the registered methods, then scan for properties of that name
that would be closures, _then_ fall back to __call. You could add this to
__call with __set() checks for assigned values being closures, but it's rather
ugly to have to do that for all class definitions.

------
deweller
I think it is worth noting here that PHP 5.4 is still in at version beta1.

I'm looking forward to this new feature, as it is cumbersome to pass anonymous
functions to object instances in 5.3.

------
dahlia
It’s an evil thing originated from JavaScript. PHP always has borrowed evil
things from other languages. As a result, PHP keeps getting more evil by the
version.

