Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76416
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.245 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <BC228A66-1337-4A4B-8B7E-E2DBC641CD1B@fb.com>
Date: Sun, 10 Aug 2014 19:20:09 +0100
Cc: Rowan Collins <rowan.collins@gmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <B142BE0C-2E6F-413B-BAC2-19F17218AA05@ajf.me>
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>
To: Josh Watzman <jwatzman@fb.com>
Subject: Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures
From: ajf@ajf.me (Andrea Faulds)

Hi!

Sorry for the slow response, I=92ve been on holiday.

On 8 Aug 2014, at 01:32, Josh Watzman <jwatzman@fb.com> wrote:

> The RFC goes a long way to fixing this, but one important place it =
misses 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 unexpected and unwanted results, as opposed to forcing the =
closure to be bound 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 =
something 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 even pre-bind it to the intended $this. Or maybe it =
technically could by calling bind() on the result of &self::priv before =
returning it, but that's very cumbersome for what is the common case for =
what you want to do with "function pointer" to a non-static method.

Unfortunately, yes, such closures are not pre-bound. However invoking it =
when it=92s unbound will produce the same error as calling any method =
statically (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 something 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.

> However, importantly, the Hack typechecker *does* constrain a lot of =
this messiness, and so the underlying implementation isn't nearly as =
important for Hack right now. But straightening this out in the runtime =
would be a big win of having real first class function references, and I =
think your RFC is missing out on making the semantics here a whole lot =
more in line with what programmers are going to expect.

I think &Foo::bar does what you=92d expect IMO, as just like Foo::bar(), =
it=92s unbound, even for self. It=92s unfortunate, but it is very simple =
to simply bind it.

> Orthogonal to the above issue, something else you may want to =
consider, since you're revisiting first class functions, is using =
Closure for this might not be what you want. (This might be partially =
what Stas was getting at as well?) If you're thinking about these as =
real first-class functions, the fact that they are objects, that you can =
add dynamic properties or re-bind() them is kind of weird.

It makes sense for methods. If you reference the method itself, you=92d =
need to bind it to call it. It makes less sense for global functions, =
but they=92re static anyway, you can=92t bind them.

Using the =91Closure=92 class is unfortunate, but I don=92t really want =
to make unnecessary new Function/Method/etc. classes given they=92d all =
share the same implementation anyway.

Maybe, should this pass, we could rename Closure to Function or =
something.

> 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.

Well, closures are immutable, to be fair. bind and bindTo actually =
produce *new* functions, and they don=92t even work on static closures =
anyway. You=92re not really doing these things to the =93real=94 =
function.

--
Andrea Faulds
http://ajf.me/