Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88687
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
To: internals@lists.php.net
References: <CA+kxMuTLCQu9hVd5o-5A=2+08nnKONbPsZ4+pzdwogk1nbPAaA@mail.gmail.com>
Message-ID: <5612B99D.8030308@gmail.com>
Date: Mon, 5 Oct 2015 18:55:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CA+kxMuTLCQu9hVd5o-5A=2+08nnKONbPsZ4+pzdwogk1nbPAaA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [DRAFT]: Consistent callables
From: rowan.collins@gmail.com (Rowan Collins)

Dan Ackroyd wrote on 29/09/2015 15:25:
> Hello internals,
>
> Here is a draft RFC to make the callable type in PHP be consistent and
> have much fewer surprises.
>
> https://wiki.php.net/rfc/consistent_callables

To break the silence: I really like the sentiment behind this, and it 
seems very thorough. I've been caught out several times by the fact that 
this appears to work:

$callback = [self, 'some_method'];

Because of the legacy "feature" of treating undefined constants as 
strings (which IMHO should be deprecated anyway, and removed in 8.0), it 
becomes this:

$callback = ['self', 'some_method'];

... and the 'self' is only evaluated when you come to run it, at which 
point it will either fatal error, or do something completely irrelevant, 
depending if that name happens to exist in the class context it finds 
itself in.


The only part I have a slight concern over is the behaviour of 
private/protected methods, but if some form of constructor is available 
to neatly wrap them into closures, I think it's acceptable to require 
its use.

The way I see it is that currently is_callable($foo) means "is $foo 
callable in the current context", whereas the proposal makes it "is $foo 
a valid value of type callable".


My only other thought is that deprecation should happen in 7.1, not 
"7.last", because a) we should give people as much warning as possible 
(as soon as the replacement functionality is available to move to) 
rather than leaving until the last minute; and b) we won't necessarily 
know that a particular release is 7.last, e.g. the decision against 
releasing a 5.7 happened 6 months after the release of 5.6.0

Regards,
-- 
Rowan Collins
[IMSoP]