valid for call_user_func[_array] and callable type-hint but invalid for
for direct variable calls:
- string "MyClass::staticFunc"
- string "self::staticFunc"
- string "static::staticFunc"
- string "parent::func"
- string "parent::staticFunc"
Thoughts ?
Hey Marc,
valid for call_user_func[_array] and callable type-hint but invalid for for direct variable calls:
- string "MyClass::staticFunc"
- string "self::staticFunc"
- string "static::staticFunc"
- string "parent::func"
- string "parent::staticFunc"
Thoughts ?
I think it’d make sense if it was supported for normal variable function calls. It’s the most intuitive behaviour.
Thanks.
Andrea Faulds
http://ajf.me/
valid for call_user_func[_array] and callable type-hint but invalid for for
direct variable calls:
- string "MyClass::staticFunc"
- string "self::staticFunc"
- string "static::staticFunc"
- string "parent::func"
- string "parent::staticFunc"
Thoughts ?
This is https://bugs.php.net/bug.php?id=68475 — Julien and I both have
PoC branches implementing this, and agree that it should be fixed in
PHP 7, although I think we differ on whether an RFC is required or
not.
Adam
Hey Adam,
valid for call_user_func[_array] and callable type-hint but invalid for for
direct variable calls:
- string "MyClass::staticFunc"
- string "self::staticFunc"
- string "static::staticFunc"
- string "parent::func"
- string "parent::staticFunc"
Thoughts ?
This is https://bugs.php.net/bug.php?id=68475 — Julien and I both have
PoC branches implementing this, and agree that it should be fixed in
PHP 7, although I think we differ on whether an RFC is required or
not.
It’s technically a 'language change’ and would affect the language specification. That said, it seems rather “no-brainer”.
--
Andrea Faulds
http://ajf.me/
Hi!
It’s technically a 'language change’ and would affect the language
specification. That said, it seems rather “no-brainer”.
I think it makes a lot of sense to have call_user_func() and $a() work
identically. I'm not sure though if it should be done by adding
'foo::bar' to $a() or removing it from call_user_func(). Adding means
stuff that wasn't callable before may be callable now which may expose
the code for some issues (though if you allow people to call arbitrary
functions in your code you're probably in trouble anyway, so it may not
be a big deal).
I think it's better to have an RFC which clearly states what is
added/removed and that call_user_func()/$a()/is_callable/callable
type/whatever else uses it - are all in sync after it and preferably use
the same code, and have tests for all options supported.
Stas Malyshev
smalyshev@gmail.com
I'm not sure though if it should be done by adding
'foo::bar' to $a() or removing it fromcall_user_func().
call_user_func('foo::bar') work since 5.2.2 (see http://3v4l.org/k2SOU).
Is there a serious reason to break code that is perfectly fine since 2007.
Breaking BC needs a serious reason IMHO.
valid for call_user_func[_array] and callable type-hint but invalid for for
direct variable calls:
- string "MyClass::staticFunc"
- string "self::staticFunc"
- string "static::staticFunc"
- string "parent::func"
- string "parent::staticFunc"
Thoughts ?
This is https://bugs.php.net/bug.php?id=68475 — Julien and I both have
PoC branches implementing this, and agree that it should be fixed in
PHP 7, although I think we differ on whether an RFC is required or
not.
If is_callable($f) returns true then it's a bug if you can't call
it with $f(...$args). That's my opinion anyway. I was actually made
aware of this bug some time ago but whenever I intended to fix it I
couldn't remember which case was the issue.
valid for call_user_func[_array] and callable type-hint but invalid for
for direct variable calls:
- string "MyClass::staticFunc"
- string "self::staticFunc"
- string "static::staticFunc"
- string "parent::func"
- string "parent::staticFunc"
Thoughts ?
I would prefer deprecating this alternative notation instead of adding more
support for it. The [$class, $method] form is the canonical form we support
everywhere and which is consistent with the [$obj, $method] callbacks.
There's no point supporting another alternative notation, especially if it
was effectively unusable for a while now already.
Nikita
On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz <dev@mabe.berlin
mailto:dev@mabe.berlin> wrote:valid for call_user_func[_array] and callable type-hint but invalid for for direct variable calls: - string "MyClass::staticFunc" - string "self::staticFunc" - string "static::staticFunc" - string "parent::func" - string "parent::staticFunc" see http://3v4l.org/1oSO3 Thoughts ?I would prefer deprecating this alternative notation instead of adding
more support for it. The [$class, $method] form is the canonical form we
support everywhere and which is consistent with the [$obj, $method]
callbacks. There's no point supporting another alternative notation,
especially if it was effectively unusable for a while now already.
I don't think removing this is an option because of a big BC for no reason.
Additionally the string alternative have some advantages:
- better usable in configurations
- return syntax of third argument of is_callable
- ...
Nikita
Marc
Hey Nikita,
valid for call_user_func[_array] and callable type-hint but invalid for
for direct variable calls:
- string "MyClass::staticFunc"
- string "self::staticFunc"
- string "static::staticFunc"
- string "parent::func"
- string "parent::staticFunc"
Thoughts ?
I would prefer deprecating this alternative notation instead of adding more
support for it. The [$class, $method] form is the canonical form we support
everywhere and which is consistent with the [$obj, $method] callbacks.
There's no point supporting another alternative notation, especially if it
was effectively unusable for a while now already.
By the way, this notation is also used by constant() and defined():
$ php -r 'class Foo { const FOO = 3; } var_dump(constant("Foo::FOO"), defined("Foo::FOO"));'
int(3)
bool(true)
It’s also very intuitive compared to the function syntax. I see no reason we shouldn’t support it more widely.
--
Andrea Faulds
http://ajf.me/
Andrea Faulds wrote on 23/01/2015 14:37:
Hey Nikita,
valid for call_user_func[_array] and callable type-hint but invalid for
for direct variable calls:
- string "MyClass::staticFunc"
- string "self::staticFunc"
- string "static::staticFunc"
- string "parent::func"
- string "parent::staticFunc"
Thoughts ?
I would prefer deprecating this alternative notation instead of adding more
support for it. The [$class, $method] form is the canonical form we support
everywhere and which is consistent with the [$obj, $method] callbacks.
There's no point supporting another alternative notation, especially if it
was effectively unusable for a while now already.
By the way, this notation is also used byconstant()anddefined():$ php -r 'class Foo { const FOO = 3; } var_dump(constant("Foo::FOO"), defined("Foo::FOO"));'
int(3)
bool(true)It’s also very intuitive compared to the function syntax. I see no reason we shouldn’t support it more widely.
+1 on this being more intuitive syntax, although the array syntax is
convenient for dynamically selecting each part separately, and obviously
for calling non-static methods.
It actually feels kind of weird that as of PHP 7, an array is more
callable than a string:
class Foo { static function bar() { echo 'Hello'; } }
Foo::bar(); // OK
'Foo', 'bar'; // OK
'Foo::bar'(); // FATAL ERROR
Regards,
Rowan Collins
[IMSoP]
Hi!
Foo::bar(); // OK
'Foo', 'bar'; // OK
'Foo::bar'(); // FATAL ERROR
I'm not sure why one would ever need/want the latter. IMO, it just looks
weird.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
Foo::bar(); // OK
'Foo', 'bar'; // OK
'Foo::bar'(); // FATAL ERRORI'm not sure why one would ever need/want the latter. IMO, it just
looks
weird.
Well, they both look weird as literals like that, but the array looks the wierder of the two to me. Representing a static call in some external configuration is an example where a single string in normal PHP syntax would make more sense than needing to create a 2-element array.
Foo::bar(); // OK
'Foo', 'bar'; // OK
'Foo::bar'(); // FATAL ERROR
Hi,
does this topic need to be addressed before PHP7 goes feature freeze? Or is
it a bugfix? (Julien already provided a patch)
I'm not familiar with writing RFCs. I fear I won't be able to handle it on
schedule if one is required.
Can someone help please?
Regards,
Nicolas
Hi all,
On Sun, Mar 15, 2015 at 7:15 PM, Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:
Foo::bar(); // OK
'Foo', 'bar'; // OK
'Foo::bar'(); // FATAL ERRORHi,
does this topic need to be addressed before PHP7 goes feature freeze? Or is
it a bugfix? (Julien already provided a patch)
I'm not familiar with writing RFCs. I fear I won't be able to handle it on
schedule if one is required.
Can someone help please?
It's nice if this bug could be fixed by PHP7.
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki yohgaki@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.
Then how would you write an callback containing an already constructed object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object->method($methodArg1, $methodArg2); };
Then how would you write an callback containing an already constructed object?
$a = [$object, 'method'];The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object->method($methodArg1, $methodArg2); };
$object->$methodName(...$args);
On Thursday 19 March 2015 18:17:50 S.A.N wrote:
Then how would you write an callback containing an already constructed
object? $a = [$object, 'method'];The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object->method($methodArg1, $methodArg2); };$object->$methodName(...$args);
That's a call. Requested was an assignment. You cannot assign that and pass it
around for later calling. You cannot pass that as a callable parameter.
Patrick
Hi,
2015-03-19 17:17 GMT+01:00 S.A.N ua.san.alex@gmail.com:
Then how would you write an callback containing an already constructed object?
$a = [$object, 'method'];The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object->method($methodArg1, $methodArg2); };$object->$methodName(...$args);
You would still need an array to pass the information about the
callback to another context. The syntax you detailed is not usable by
the callable typehint and internal functions requiring a callback. No
improvement made. The better alternative may be to deprecate strings
as callbacks (if one should be deprecated at all) and always require a
closure or or an array with one of the following signatures
array(string); array(string, string); array(object, string)
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')
Sebastian B.-Hagensen wrote on 19/03/2015 16:27:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')
Andrea proposed a slightly different syntax for function references a
few months back - see withdrawn RFC [1] and accompanying Internals
thread [2].
I actually quite like the callable() syntax. Whereas Andrea's suggestion
was a parser rule that took a bare string, like &foo, this would have to
always take a string, like callable('foo'), but that's good if we want
to roll in dynamic callbacks as well:
Right now, we have to embed the type information in the variable name,
because this is just a string:
$hook_callback = 'hook_' . $hook_name;
This has a much strong information scent:
$hook = callable('hook_' . $hook_name);
There's then the question of what kind of object it would return - a
Closure? Some child or sibling of Closure? What methods could be
usefully provided?
What should happen if the arguments provided aren't callable? Throw an
exception?
Also, do we still need a way to delay testing of callability, to allow this:
class A {
private function foo() { echo 'foo'; }
public function bar(callable $call) { $call(); }
}
$a = new A;
// A::foo is not callable here, but will be when we get inside A::bar
var_dump(is_callable([$a, 'foo'] ));
$a->bar( [$a, 'foo'] );
Currently works: http://3v4l.org/pNZgn
[1] https://wiki.php.net/rfc/function_referencing
[2] http://marc.info/?t=140710275400001&r=2&w=2
Regards,
Rowan Collins
[IMSoP]
There's then the question of what kind of object it would return - a
Closure? Some child or sibling of Closure? What methods could be usefully
provided?
Yes, it's a closure. I've actually fleshed this out quite a bit, and
there are a few important questions:
- With methods do you allow unbound closures?
callable("Foo::method")? - How do you provide a context object? Two parameters? If so, what
order? The object first makes more sense, but that means you have a
string for your first parameter when there is only one, but an object
if there are two. So you put the context second and it's kind of weird
to docallable("method", $foo)
Also note that if we had a unified table for properties, methods and
constatns this is vastly simplified:
- $foo::method could provide an unbound, scoped closure
- $foo->method could provide a bound closure
Or you do alternative grammar rules inside of callable, such that
callable(foo::method) must would check for a method instead of a
constant.
All in all, I really wish we had unified properties, methods and
constants. It would also have the advantage that if you have a
property of an object that is a callable you could call it with normal
syntax $foo->property() instead of having to do things like $f = $foo->property; $f().
Callable might work, though.
Hi,
Am 19.03.2015 um 17:27 schrieb Sebastian B.-Hagensen:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')
but before that happens, we should make closures serializable.
Greets
Dennis
Hi,
Am 19.03.2015 um 17:27 schrieb Sebastian B.-Hagensen:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')but before that happens, we should make closures serializable.
What does closures being serializable have to do with this feature?
Hi,
Am 19.03.2015 um 20:26 schrieb Levi Morrison:
Hi,
Am 19.03.2015 um 17:27 schrieb Sebastian B.-Hagensen:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')but before that happens, we should make closures serializable.
What does closures being serializable have to do with this feature?
If you replace the array($object, 'method') syntax by callable($object,
'method') which returns a closure, you can not serialize callables any
more which is currently possible. Before we replace working language
features by closures we should update closures to be usable in all
required situations.
Greets
Dennis
Hi,
Am 19.03.2015 um 20:26 schrieb Levi Morrison:
Hi,
Am 19.03.2015 um 17:27 schrieb Sebastian B.-Hagensen:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')but before that happens, we should make closures serializable.
What does closures being serializable have to do with this feature?If you replace the array($object, 'method') syntax by callable($object,
'method') which returns a closure, you can not serialize callables any
more which is currently possible. Before we replace working language
features by closures we should update closures to be usable in all
required situations.
Many callable are inherently not serializable. This is not solvable in
the general case.
Why are you serializing array($object, "method") callable currently?
(As in, what is the use case?)
Am 19.03.2015 um 22:11 schrieb Levi Morrison:
Hi,
Am 19.03.2015 um 20:26 schrieb Levi Morrison:
Hi,
Am 19.03.2015 um 17:27 schrieb Sebastian B.-Hagensen:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')but before that happens, we should make closures serializable.
What does closures being serializable have to do with this feature?If you replace the array($object, 'method') syntax by callable($object,
'method') which returns a closure, you can not serialize callables any
more which is currently possible. Before we replace working language
features by closures we should update closures to be usable in all
required situations.Many callable are inherently not serializable. This is not solvable in
the general case.Why are you serializing array($object, "method") callable currently?
(As in, what is the use case?)
passing callbacks to a worker process, storing an object structure with
a their of event handlers, etc.
Hi Sebastian,
On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen <
sbj.ml.read@gmail.com> wrote:
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki yohgaki@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.Then how would you write an callback containing an already constructed
object?
$a = [$object, 'method'];The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object->method($methodArg1, $methodArg2); };
I'm not proposing deprecate it soon, but in the long run.
It will need a decade to deprecate it.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Sebastian,
On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen
<sbj.ml.read@gmail.com mailto:sbj.ml.read@gmail.com> wrote:2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki <yohgaki@ohgaki.net <mailto:yohgaki@ohgaki.net>>: > Distinguishing array and callable is problematic. > Array callable is better to be deprecated in the long run. IMHO. Then how would you write an callback containing an already constructed object? $a = [$object, 'method']; The alternative is unnecessarily cumbersome: $a = function($methodArg1, $methodArg2) use($object) { return $object->method($methodArg1, $methodArg2); };I'm not proposing deprecate it soon, but in the long run.
It will need a decade to deprecate it.
It is not time that is needed, but an alternative way of expressing "use
this instance method as a callback", such as those discussed elsewhere
in the thread.
Regards,
--
Rowan Collins
[IMSoP]
Hi Rowan,
On Fri, Mar 20, 2015 at 7:12 AM, Rowan Collins rowan.collins@gmail.com
wrote:
Hi Sebastian,
On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen <
sbj.ml.read@gmail.com mailto:sbj.ml.read@gmail.com> wrote:2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki <yohgaki@ohgaki.net <mailto:yohgaki@ohgaki.net>>: > Distinguishing array and callable is problematic. > Array callable is better to be deprecated in the long run. IMHO. Then how would you write an callback containing an already constructed object? $a = [$object, 'method']; The alternative is unnecessarily cumbersome: $a = function($methodArg1, $methodArg2) use($object) { return $object->method($methodArg1, $methodArg2); };I'm not proposing deprecate it soon, but in the long run.
It will need a decade to deprecate it.It is not time that is needed, but an alternative way of expressing "use
this instance method as a callback", such as those discussed elsewhere in
the thread.
I replied how it could be deprecated.
I'm not commenting for it, but the deprecation discussion.
You cannot restrict discussion to what you would want, can it?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Rowan,
On Fri, Mar 20, 2015 at 7:12 AM, Rowan Collins
<rowan.collins@gmail.com mailto:rowan.collins@gmail.com> wrote:Hi Sebastian, On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen <sbj.ml.read@gmail.com <mailto:sbj.ml.read@gmail.com> <mailto:sbj.ml.read@gmail.com <mailto:sbj.ml.read@gmail.com>>> wrote: 2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki <yohgaki@ohgaki.net <mailto:yohgaki@ohgaki.net> <mailto:yohgaki@ohgaki.net <mailto:yohgaki@ohgaki.net>>>: > Distinguishing array and callable is problematic. > Array callable is better to be deprecated in the long run. IMHO. Then how would you write an callback containing an already constructed object? $a = [$object, 'method']; The alternative is unnecessarily cumbersome: $a = function($methodArg1, $methodArg2) use($object) { return $object->method($methodArg1, $methodArg2); }; I'm not proposing deprecate it soon, but in the long run. It will need a decade to deprecate it. It is not time that is needed, but an alternative way of expressing "use this instance method as a callback", such as those discussed elsewhere in the thread.I replied how it could be deprecated.
I'm not commenting for it, but the deprecation discussion.
You cannot restrict discussion to what you would want, can it?
I had no intention of restricting the discussion in any way, apologies
if it came across that way.
Perhaps what I should have said is it is not only time that is needed
- we need to design the replacement before it's worth even thinking
about deprecating something.
Regards,
--
Rowan Collins
[IMSoP]
Hi Rowan,
On Fri, Mar 20, 2015 at 8:00 AM, Rowan Collins rowan.collins@gmail.com
wrote:
I had no intention of restricting the discussion in any way, apologies if
it came across that way.Perhaps what I should have said is it is not only time that is needed -
we need to design the replacement before it's worth even thinking about
deprecating something.
Deprecation is future scope that may be years later if it may.
I fully agree. I would like to fix this bug now. Current behavior is very
annoying...
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net