Re: [RFC]

From: Date: Wed, 12 Feb 2020 07:12:53 +0000
Subject: Re: [RFC]
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-108505@lists.php.net to get a copy of this message
On Wed, Feb 12, 2020 at 4:58 AM Mike Schinkel <mike@newclarity.net> wrote: > > Or best would be to add ::nameof for functions, method, classes, interfaces and traits One problem is how would x::nameof resolve when you have several x symbols (of distinct kinds) in scope? ``` namespace Theirs { class Foo {} const BAR = 2; function qux() { return '3'; } } namespace Mine { use Theirs\Foo as x; use const Theirs\BAR as x; use function Theirs\qux as x; var_dump(new x); // object(Theirs\Foo)#1 var_dump(x); // int(2) var_dump(x()); // string(1) "3" // *** hypothetical: *** assert(x::class === 'Theirs\Foo'); assert(x::const === 'Theirs\BAR'); assert(x::function === 'Theirs\qux'); assert(x::nameof === ???); } ``` > Returning a _closure_ instead of a string would be providing a feature we _already_ have > instead of one we do _not_ have. > > If we had ::function returning a string we could use Closure::fromCallable() to get a closure. > Or today just use fn() => myfunc(). > > But if ::function instead returned a closure then there still would be no way to extract the > name of a function as a string from a symbol where PHP can throw a warning if it does not recognize > the symbol, such as in the case of a typo. > > Seems to me having a shorter syntax to get a closure is an orthogonal concern. > > If we want a shorthand for closure we should create an additional syntax for it but still > provide a way to extract a function's name as a string from its symbol since that is currently > _not_ possible. Getting a closure from a function symbol currently _is_ possible. > > Much better to provide ::function to return the name of the function and ::closure get a > closure that can call the function. > > Or have ::function to return the name of the function and provide a syntax something like > ${myfunc} to return a closure, which has been suggested later in this thread. That might deserve consideration indeed... -- Guilliam Xavier

« previous php.internals (#108505) next »