Re: Closures as methods (and Closure::bind)

On Wed, 11 Aug 2010 14:57:47 +0100, Johannes Schlüter <johannes@schlueters.de> wrote:

On Wed, 2010-08-11 at 14:38 +0100, Gustavo Lopes wrote:

I've updated the wiki page for "Closures with objects extension" with things that are in "Proposal A with modification"s but are not implemented: http://wiki.php.net/rfc/closures/object-extension#status_as_of_august_10_2010 I propose an implementation of "closures stored in properties used as methods", as in: $this->prop = function () { ...} $this->prop(); A few issues that may merit discussion (copied from the wiki page):

A few more things coming to mind without much thought:

      * What if both a method and a property with the name exist?

An existing method has priority over closure-as-method, just like it has priority over __call. I implemented what was in the modified proposal A. Personally, I think __call should have priority over closure-as-method so as to not to break BC.

      * What about allowing properties with function names as strings or
        array($obj_or_class, 'method'), won't that be needed for being
        consistent with local variables?

Well, you cannot do "$a = 'phpinfo'; $a();" as well, so it's consistent with that. I think what you refer to would only make sense if that were allowed.

              * In the array($object, 'method') case: What's the scope
                for $this?

call_user_func(array($object, 'method')) is the same as $object->method(), the calling scope is that whatever scope is defined for the closure. The value of $this is the object that's bound to the closure; an E_WARNING notice is raised if $this !== $object (as mentioned in the proposal).. class A { public $prop; } $a1 = new A; $a2 = new A; $a1->prop = Closure::bind(function () { var_dump($this); }, $a2); call_user_func(array($a1, 'prop')); gives: Warning: Closure called as method but bound object differs from containing object in ... object(A)#2 (1) { ["prop"]=> NULL }

I don#t have an opinion on this feature, yet, I like the current class-based object model as reading code is relatively simple, with this addition (and the fact that you can create properties on the fly) we create a powerful tool for really hard to read code.

We could forbid using dynamic properties for this functionality, though I'd say it's arguably useful. -- Gustavo Lopes