Re: Inconsistencies in callable, call_user_func and direct variable calls

Andrea Faulds wrote on 23/01/2015 14:37:

Hey Nikita,

On 20 Jan 2015, at 21:46, Nikita Popov <nikita.ppv@gmail.com> wrote: On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz <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.

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.

+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 http://3v4l.org/f7rvc Regards, -- Rowan Collins [IMSoP]