On Wed, 11 Aug 2010 14:57:47 +0100, Johannes Schlüter
<johan...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
