Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49337
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=iso-8859-15; format=flowed; delsp=yes
To: =?iso-8859-15?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <op.vg9z5z0ridpuyk@cataphract-old.dulce.lo.geleia.net>
 <1281535067.1132.15.camel@guybrush>
Date: Wed, 11 Aug 2010 15:29:50 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
Organization: =?iso-8859-15?Q?N=FAcleo_de_Eng=2E_Biom=E9dica_?=
 =?iso-8859-15?Q?do_IST?=
Message-ID: <op.vg92j0whidpuyk@cataphract-old.dulce.lo.geleia.net>
In-Reply-To: <1281535067.1132.15.camel@guybrush>
User-Agent: Opera Mail/10.60 (Win32)
Subject: Re: [PHP-DEV] Closures as methods (and Closure::bind)
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Wed, 11 Aug 2010 14:57:47 +0100, Johannes Schl=FCter  =

<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 =3D 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 s=
o  =

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 =3D 'phpinfo'; $a();" as well, so it's consisten=
t  =

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 !=3D=3D $object (as mentioned in the proposal)=
.


class A {
public $prop;
}
$a1 =3D new A;
$a2 =3D new A;
$a1->prop =3D Closure::bind(function () { var_dump($this); }, $a2);
call_user_func(array($a1, 'prop'));

gives:

Warning: Closure called as method but bound object differs from containi=
ng  =

object in ...
object(A)#2 (1) {
   ["prop"]=3D>
   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 th=
is
> 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