Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76409
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+MQ2x55vAdcmAgABbUYCAAH23AIAAAi0AgAUGAgA=
Date: Fri, 8 Aug 2014 00:32:17 +0000
Message-ID: <BC228A66-1337-4A4B-8B7E-E2DBC641CD1B@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>
In-Reply-To: <BDDFD20F-1885-4106-BA7E-2A837C02ADF9@ajf.me>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <E68FF902A4BD844780C166CC0020D49F@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)

[Andrea, please forward this to internals if you don't see my message appea=
r there in a few hours; as you know, FB is working through issues sending e=
mail to internals, and though I think I know how to get it through, if it d=
oesn't make it, please help :) Thanks!]

On Aug 4, 2014, at 12:49 PM, Andrea Faulds <ajf@ajf.me> wrote:

> IMO, it=92d also be good for Hack as it could use this instead of fun().

Yep! I don't think there's a single engineer or user of Hack that doesn't t=
hink that Hack's current solution to this is pretty awful :-P (For those un=
familiar, see http://docs.hhvm.com/manual/en/book.hackmagic.php, in particu=
lar fun/class_meth/inst_meth/meth_caller.)

So I love the idea of making a Hack syntax for this that doesn't suck and a=
 PHP syntax at all. However, I think the current proposal misses an opportu=
nity to fix an important issue with "strings as first-class functions" as i=
t currently stands in PHP, which is how those strings deal with scope. The =
short version is that scope, e.g., for calling private methods, is going to=
 be checked when you invoke the method via call_user_func/cufa, which is pr=
obably not what the programmer would expect -- you usually want a check whe=
n you *create* the string/array/whatever that you will eventually pass into=
 cuf/cufa. It gets a ton more hairy than that -- https://github.com/faceboo=
k/hhvm/blob/master/hphp/test/quick/cuf.php is an HHVM test case that is a l=
itany of all of the weird ways you can use cuf and how it applies to scope.

The RFC goes a long way to fixing this, but one important place it misses i=
s with function references to private and protected methods. The crux of th=
e issue is that allowing an unbound closure to escape can lead to very unex=
pected and unwanted results, as opposed to forcing the closure to be bound =
to a particular variable. Consider:

<?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;
  }
}

While this example is somewhat contrived, I've certainly wanted to do somet=
hing 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 onl=
y 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 c=
umbersome for what is the common case for what you want to do with "functio=
n pointer" to a non-static method.

FWIW the current kludge Hack does with its magic functions don't quite get =
this right either; inst_meth binds to a specific method and in principle sh=
ould be able to call private/protected methods though I think it can't righ=
t now due to being on top of strings; meth_caller doesn't bind to a specifi=
c method and can't call private/protected methods, as it should be. However=
, importantly, the Hack typechecker *does* constrain a lot of this messines=
s, 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 missin=
g out on making the semantics here a whole lot more in line with what progr=
ammers are going to expect.

Orthogonal to the above issue, something else you may want to consider, sin=
ce 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 f=
act that they are objects, that you can add dynamic properties or re-bind()=
 them is kind of weird. You can't do any of those things to the "real" func=
tion, so it's unclear if it makes sense to be able to do it to the callable=
 reference. (That said, differing here gets into a whole lot of other issue=
s around potentially being confusing when differing from the existing way o=
f representing lambdas via Closure.)

Josh Watzman