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):
- Do we really want to make closures-as-methods have priority over
__call/__callStatic? On one hand, there's no way to otherwise allow
closures-as-methods in classes that implement these magic methods, on the
other one, this breaks BC and makes the magic methods even more
inefficient – we have to check if there is a method and a property with
that name.
- Properties are not case-sensitive, hence calling closures-as-methods is
case-sensitive (contrary to calling regular methods).
- What to do with properties with no visibility? Ignore them (and let fall
back to __call/__callStatic) or raise error (the implementation in the
patch raises an error).
- What to do with properties used as methods that are not closures? Ignore
them or raise an error (the implementation raises an error).
- Should we throw an exception when calling a closure-as-instance method
that's stored as a static method? Usually, accessing a static property in
a non static context raises an E_STRICT, but I think may very well be very
useful, because we can swap instance method implementations on a class
basis instead of only an instance basis.
I've also updated the "bindTo" behavior change and document it in the same
wiki page. Compared to the previous patch I'd sent, this implementation
has more tests, moves getScope to reflection (a getClosureScopeClass that
returns a ReflectionClass) and allows binding objects with NULL scope
(uses a dummy scope instead) instead of silently refusing to bind the
object.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
