Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76444
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain fb.com does not designate 67.231.153.30 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>
CC: Rowan Collins <rowan.collins@gmail.com>,
        "internals@lists.php.net"
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Closure::call and Function Referencing as
 Closures
Thread-Index: AQHPr2UX6cWu/Jgb6EeTLZp+MQ2x55vAdcmAgABbUYCAAH23AIAAAi0AgAUGAgCABE79gIABzgQA
Date: Mon, 11 Aug 2014 21:53:46 +0000
Message-ID: <301B540D-FF37-4293-A2BD-2A345D84BDB8@fb.com>
References: <D17EB1B8-7A7E-419B-AF55-0ADCAB4CFEB3@ajf.me>
 <53DF2BED.10103@sugarcrm.com> <06F3EF08-21B1-49AD-9D9D-5043C69AC1D8@ajf.me>
 <53DFE1FC.5040206@gmail.com> <BDDFD20F-1885-4106-BA7E-2A837C02ADF9@ajf.me>
 <BC228A66-1337-4A4B-8B7E-E2DBC641CD1B@fb.com>
 <B142BE0C-2E6F-413B-BAC2-19F17218AA05@ajf.me>
In-Reply-To: <B142BE0C-2E6F-413B-BAC2-19F17218AA05@ajf.me>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <3AB52E64790E924A9631A6A37BBAC827@fb.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as
 Closures
From: jwatzman@fb.com (Josh Watzman)

On Aug 10, 2014, at 11:20 AM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi!
>=20
> Sorry for the slow response, I=92ve been on holiday.

No problem!

> On 8 Aug 2014, at 01:32, Josh Watzman <jwatzman@fb.com> wrote:
>=20
>> The RFC goes a long way to fixing this, but one important place it misse=
s is with function references to private and protected methods. The crux of=
 the issue is that allowing an unbound closure to escape can lead to very u=
nexpected and unwanted results, as opposed to forcing the closure to be bou=
nd to a particular variable. Consider:
>>=20
>> <?php
>> class C {
>> private function priv() { /* ... */ }
>> public function pub() {
>>   // ... do stuff ...
>>   // Return a closure for the caller to call priv at a later date:
>>   return &self::priv;
>> }
>> }
>>=20
>> While this example is somewhat contrived, I've certainly wanted to do so=
mething similar before. The intent of this code is for the closure returned=
 by "pub" to only ever be called on what was $this inside "pub" -- but not =
only can you change that with bind() on the closure, "pub" itself cannot ev=
en pre-bind it to the intended $this. Or maybe it technically could by call=
ing bind() on the result of &self::priv before returning it, but that's ver=
y cumbersome for what is the common case for what you want to do with "func=
tion pointer" to a non-static method.
>=20
> Unfortunately, yes, such closures are not pre-bound. However invoking it =
when it=92s unbound will produce the same error as calling any method stati=
cally (E_STRICT or E_ERROR), so the issue can be noticed and fixed easily. =
It=92s possible to bind with Closure::bind(&Foo::bar, =91Foo=92); or someth=
ing like that. I could make it pre-bind, but I=92m unwilling to as :: never=
 binds when calling, so it shouldn=92t when referencing for consistency.

My point is not that you might forget to bind() the Closure, agree that it'=
s taken care of just fine as-is. My point is that there's no way for pub() =
to express that it only ever expects the closure returned to be bound to th=
e object on which you called pub(). Not only is the caller free to bind it =
to some other variable, but the bug might not be obvious at all since there=
's nothing constraining the call to bind() to happen nearby to the code in =
pub() where the intent that it only be bound to that object is clear. Every=
thing here is conventional, when IMO it should be contractual, most especia=
lly since an unbound Closure isn't even meaningful to use (except to bind i=
t before using it).

>> You can't do any of those things to the "real" function, so it's unclear=
 if it makes sense to be able to do it to the callable reference.
>=20
> Well, closures are immutable, to be fair. bind and bindTo actually produc=
e *new* functions, and they don=92t even work on static closures anyway. Yo=
u=92re not really doing these things to the =93real=94 function.

Ah, whoops -- it's apparently an HHVM-ism that you can add properties to Cl=
osures :) http://3v4l.org/adEgO The rest of the point I was making here bas=
ically boils down to being able to bind/re-bind them, which is the same as =
the one I'm trying to make above, so I won't belabor it.

Josh Watzman