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
This RFC is probably not ready for the formal discussion that is held
before a vote on it can be held as there may be some more details of
what changes are necessary lurking, waiting to be found, in the PHP
source code. However I would like to gather feedback about the
likelihood of the RFC passing, as implementing a patch for this RFC is
likely to be a significant amount of work.
And yes most of this RFC targets PHP 8 with only small parts for 7.1.
I realise that it is easy to think that it's a bit early to start
thinking about that before 7 is out the door, but as there was a
stampede of RFCs for PHP 7, I think the earlier RFCs can be discussed
the better. Depending on the feedback, I imagine I would put this RFC
up for a formal discussion and vote early in the new year.
cheers
Dan
Ack
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.
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]
Hi Dan.
Had this email in the "need-to-read" pile for over a week and finally got
the time to go though the RFC.
Seems like this is something that we need to address. Inconsistencies are
never good.
The only thing I want to point out is that is_callable as well as
method_exists don't state in the manual that the functions or methods
referred is visible.
To make this function implied I think the manual should be updated to state
it.
For instance
public class A {
private function foo() {}
}
method_exists(new A(), "foo") is technically true.
The method exist but is not visible from your context. For instance when
you use reflection you might want to find any method that exists? Or should
that be handled by the pure reflection API? Either way I think the manual
needs to state this clearly.
Best regards
Daniel
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
This RFC is probably not ready for the formal discussion that is held
before a vote on it can be held as there may be some more details of
what changes are necessary lurking, waiting to be found, in the PHP
source code. However I would like to gather feedback about the
likelihood of the RFC passing, as implementing a patch for this RFC is
likely to be a significant amount of work.And yes most of this RFC targets PHP 8 with only small parts for 7.1.
I realise that it is easy to think that it's a bit early to start
thinking about that before 7 is out the door, but as there was a
stampede of RFCs for PHP 7, I think the earlier RFCs can be discussed
the better. Depending on the feedback, I imagine I would put this RFC
up for a formal discussion and vote early in the new year.cheers
Dan
Ack
Hello internals,
Here is a draft RFC to make the callable type in PHP be consistent and
have much fewer surprises.
Hello again,
I'd like to give everyone an update on the 'Consitent Callables RFC'
https://wiki.php.net/rfc/consistent_callables
It was brought to my attention that the main piece of work for this
RFC that would need to target PHP 7.1 was actually already implemented
in PHP 5.5, and that self::class, and parent::class already resolve to
the correct classnames, i.e. the code below already works.
As it won't be feasible to introduce the main change before PHP 8, I
plan to wait to formally propose the RFC until closer to the time when
we are thinking of starting PHP 8 development, or probably around June
2017 - whichever comes first.
cheers
Dan
class A {
public static function whoAreYou() {
echo "I am A!\n";
}
}
class B extends A {
public static function whoAreYou() {
echo "I am B!\n";
}
public static function test() {
$fn = [parent::class, 'whoAreYou'];
$fn();
$fn = [self::class, 'whoAreYou'];
$fn();
}
}
B::test();
Personally, I do use "colon separated string" to e.g. put callables as keys
in an array (when of course the array definition I'm writing is fine with
static callables).
The reasons written in the RFC seem very weak compared to breaking code
that works perfectly fine today.
Just my 2cts...
Thanks for your consideration,
Nicolas