Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76417
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <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> <B142BE0C-2E6F-413B-BAC2-19F17218AA05@ajf.me>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Sun, 10 Aug 2014 22:00:10 +0100
To: Andrea Faulds <ajf@ajf.me>
CC: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <4c89fa2a-a4da-46a9-9872-6d2e5346fed1@email.android.com>
Subject: Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures
From: rowan.collins@gmail.com (Rowan Collins)

On 10 August 2014 19:20:09 GMT+01:00, Andrea Faulds <ajf@ajf.me> wrote:
>Hi!
>
>Sorry for the slow response, I’ve 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:
>> 
>> <?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
>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’s 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’s possible to bind with Closure::bind(&Foo::bar, ‘Foo’); or
>something like that. I could make it pre-bind, but I’m unwilling to as
>:: never binds when calling, so it shouldn’t when referencing for
>consistency.
>

You're rather pre-supposing the proposed syntax there, and letting it lead the semantics rather than vice versa. The point is it would be useful to allow creation of a pre-bound closure based on an existing method, so it would be good if the syntax allowed that possibility.

Getting a static reference to a non-static method and then binding it feels a bit like JS, which has a completely different notion of what a method is. And it's noteworthy that pre-bound methods are one of the things being added in ECMAScript.next


>Using the ‘Closure’ class is unfortunate, but I don’t really want to
>make unnecessary new Function/Method/etc. classes given they’d all
>share the same implementation anyway.

I'm not so sure they'd be identical - a static method or plain function would presumably error if you tried to bind it, for instance. For whatever reason, there's a tendency for internal classes to take on multiple responsibilities which a userland framework would separate out - SimpleXML is the extreme example. If we were designing a fully OO language with first-class functions (which, clearly, we're not), a hierarchy of classes to represent different "states" of these immutable objects would be the obvious choice. The alternative (which SimpleXML is also missing, incidentally) is to have one class, but include methods for interrogating its type - e.g. isBound(), isBindable(), etc

-- 
Rowan Collins
[IMSoP]