Hi Nikita,
I would like to just express my feelings. It's a definite YES from me for
first-class callables. We need something to replace [$this,
'privateMethod'].
I just don't like the proposed syntax. The triple period '...' has a
meaning already and reusing the same syntax isn't nice.
I haven't followed the PFA RFC closely, but I don't like that proposal as
it seems to add additional complexity to PHP's syntax for little gain. I
feel like it's just arrow function on steroids.
I know we can already do something like this:
function do_stuff($e) { return $e**2; }
$result = array_map(do_stuff::class, [1,2,3,4]);
I wouldn't mind having a dedicated operator for creating closures in the
same way. e.g.
$result = array_map(do_stuff::closure, [1,2,3,4]);
I understand that ::class creates a string literal and ::closure creates
closure, but from the usability point of view, they would be used in
similar ways.
Many languages have shared symbol tables for constants, functions and
variables. PHP doesn't, so we can't just use the name, but I agree with
Rowan that just using a function's name would be ambiguous even if the
parser allowed for that. We could introduce new syntax for this. I think
Kotlin uses double semicolon in front of the identifier. e.g.
$result = array_map(::do_stuff, [1,2,3,4]);
This would be less confusing than the (...) syntax IMHO. Of course this
still has the same ambiguity as Rowan points out. Is ::$objA->methA a
property or a method? We could solve this problem by specifying the syntax
to always refer to methods/functions. Parentheses could be used to enforce
access to property, e.g. ::($objA->methA) would evaluate the value stored
in the public property of the object $objA
If we land on using the syntax as your RFC proposes then I would ask
Internals to avoid (...) and instead use another symbol inside the
parentheses. I believe any other symbol would look better than triple
period, e.g. $objA->methA(*)
Kind Regards,
Kamil
