Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49329
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "internals@lists.php.net" <internals@lists.php.net>
Date: Wed, 11 Aug 2010 14:38:14 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_IST?=
Message-ID: <op.vg9z5z0ridpuyk@cataphract-old.dulce.lo.geleia.net>
User-Agent: Opera Mail/10.60 (Win32)
Subject: Closures as methods (and Closure::bind)
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

I've updated the wiki page for "Closures with objects extension" with  =

things that are in "Proposal A with modification"s but are not implement=
ed:

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 =3D 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 th=
e  =

other one, this breaks BC and makes the magic methods even more  =

inefficient =E2=80=93 we have to check if there is a method and a proper=
ty with  =

that name.
- Properties are not case-sensitive, hence calling closures-as-methods i=
s  =

case-sensitive (contrary to calling regular methods).
- What to do with properties with no visibility? Ignore them (and let fa=
ll  =

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? Igno=
re  =

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 i=
n  =

a non static context raises an E_STRICT, but I think may very well be ve=
ry  =

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 sa=
me  =

wiki page. Compared to the previous patch I'd sent, this implementation =
 =

has more tests, moves getScope to reflection (a getClosureScopeClass tha=
t  =

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