Hello internals,
Looking for feedback on the idea of supporting ::function syntax (or
::fn) for consistency with existing ::class syntax:
$arr = ['apple'];
print_r(array_map(strtoupper::function, $arr));
(Apologies if this has already been discussed. Hard to search for
colon-colon-function.)
Benefits in my view are readability and potential use in static analysis.
Downsides (as implemented in proof-of-concept) are that it can be
needlessly littered in a lot of places, and that it breaks class consts
named function. I'd vote against it in its current state, but if people
like the general idea maybe the drawbacks can be addressed with a better
implementation.
Examples:
https://gist.github.com/adsr/2c0b9243986418af3cecf8046657304b
Proof-of-concept:
https://github.com/adsr/php-src/commit/07bb24243022ccef5823f6977d231f3535a48a07.patch
Adam
Hello internals,
Looking for feedback on the idea of supporting
::functionsyntax (or
::fn) for consistency with existing::classsyntax:$arr = ['apple']; print_r(array_map(strtoupper::function, $arr));(Apologies if this has already been discussed. Hard to search for
colon-colon-function.)Benefits in my view are readability and potential use in static analysis.
Downsides (as implemented in proof-of-concept) are that it can be
needlessly littered in a lot of places, and that it breaks class consts
namedfunction. I'd vote against it in its current state, but if people
like the general idea maybe the drawbacks can be addressed with a better
implementation.Examples:
https://gist.github.com/adsr/2c0b9243986418af3cecf8046657304bProof-of-concept:
https://github.com/adsr/php-src/commit/07bb24243022ccef5823f6977d231f3535a48a07.patchAdam
There was some discussion earlier this year, although if memory serves it was in a thread whose name would not be helpful for searching. Sorry, can't help there. :-/ (Maybe it was in the threads talking about ::class notation on objects? Just a guess.)
Working strictly from memory:
- There was a lot of support in concept, but not universal.
- There was a lot of concern that ::function was just too damned long to type, so plenty of bikeshedding about shorter names.
- There's another RFC proposed that is currently stalled due to lack of time to add partial function application, which would kinda allow something similar-ish through a back door: https://wiki.php.net/rfc/partial_function_application . That said, I don't think they would conflict so I'd be fine with both happening.
+1 from me in concept.
--Larry Garfield
There was some discussion earlier this year, although if memory serves it was in a thread whose name would not be helpful for searching.
Here it is: https://externals.io/message/108459
Some of the key points (not an exhaustive summary):
-
Looking up a function's fully-qualified name would need to check at
run-time for the function's existence, since there are two possibilities
for any name that's not already fully-qualified ('foo' and
'current\namespace\foo'). This is different from ::class which (in most
cases) resolves the expression to a name at compile-time based on
current imports, and can resolve to a completely non-existent name.
There are cases where it resolves at run-time [see
https://wiki.php.net/rfc/class_name_literal_on_object] but none have the
case of "valid name but no such class defined", which would need to be
handled for functions. -
There was some discussion about the usefulness of returning the name,
or a callable object, or some way of providing both. Suggestions
included adding two new syntaxes, ::function and ::closure; simplifying
the creation of a callable object from a string; or returning an object
from which the name could be retrieved. -
Should (and could) the new syntax work with methods as well, e.g.
Foo::bar::function and $foo->bar::function. If foo::function returns a
string, these would logically need to return
['Fully\Qualified\Name\Of\Foo', 'bar'] and [$foo, 'bar'] respectively;
if it (or a variant of it) returns a Closure, it would be the
(optimized) equivalent of passing those to Closure::fromCallable.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
Hi,
what about resolving directly to Closure?
strtoupper::function === \Closure::fromCallable('strtoupper').
$this->method::function === \Closure::fromCallable([$this, 'method']).
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
Hello internals,
Looking for feedback on the idea of supporting
::functionsyntax (or
::fn) for consistency with existing::classsyntax:$arr = ['apple'];
print_r(array_map(strtoupper::function, $arr));(Apologies if this has already been discussed. Hard to search for
colon-colon-function.)Benefits in my view are readability and potential use in static analysis.
Downsides (as implemented in proof-of-concept) are that it can be
needlessly littered in a lot of places, and that it breaks class consts
namedfunction. I'd vote against it in its current state, but if people
like the general idea maybe the drawbacks can be addressed with a better
implementation.Examples:
https://gist.github.com/adsr/2c0b9243986418af3cecf8046657304bProof-of-concept:
https://github.com/adsr/php-src/commit/07bb24243022ccef5823f6977d231f3535a48a07.patchAdam
Hey Michael,
http://ocramius.github.com/
On Sun, Nov 8, 2020 at 9:38 AM Michael Voříšek - ČVUT FEL <
vorismi3@fel.cvut.cz> wrote:
Hi,
what about resolving directly to Closure?
strtoupper::function === \Closure::fromCallable('strtoupper').
$this->method::function === \Closure::fromCallable([$this, 'method']).
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
From a tooling point of view, it would be super-interesting to get a FQN of
the function, instead of a closure (which is just \Closure).
In this snippet, I'd expect the output to be foo\bar\baz\taz:
<?php
use function foo\bar\baz;
echo baz\taz::function;
Not sure if string is enough, but it worked really well for ::class,
for which tools like psalm now have a dedicated class-string type :-)
Marco Pivetta