> On Feb 12, 2020, at 5:47 PM, Rowan Tommins <[email protected]> wrote:
>
> On 12/02/2020 03:58, Mike Schinkel wrote:
>> Returning a_closure_ instead of a string would be providing a feature
>> we_already_ have instead of one we do_not_ have.
>
>
> Not really, because you still need a way to get the fully-qualified name of
> the function. This is not valid:
>
> namespace MyVendor\Something\Foo;
> function bar() {}
>
> \Closure::fromCallable('bar'); # Error: tries to resolve function '\bar'
>
Why would ::function return a short name instead of the fully-qualified name?
::function should return the fully-qualified name as does ::class. Then the
concern you state becomes a non-issue.
If ::function returns a fully qualified name developers can always use string
functions to get the short name if they need it.
> So if we had ::function which returned the name, and ::callable that returned
> a closure, the following would be equivalent:
>
> namespace MyVendor\Something\Foo;
> function bar() {}
>
> \Closure::fromCallable('MyVendor\Something\Foo\bar');
> \Closure::fromCallable(bar::function);
> bar::callable;
>
> One combination would be ::function returning a string, and $() accepting
> one, which would give:
>
> $(bar::function)
>
> In practice, that would almost certainly be optimised into one instruction,
> so the main advantage would be consistency, unless there are use cases where
> a string rather than "any callable" is actually required.
Yes.
>> Or today just use fn() => myfunc().
>
>
> That's not quite the same either: at the very least, you need to define it as
> fn(...$args) => myfunc(...$args) to pass through the parameters.
Assuming there are parameters.
> But Closure::callable is able to copy the signature of the original function,
> including type information [1], so our hypothetical ::callable could do the
> same.
True.
-------
As an aside, I wish we had a new simpler form of metadata object that could
provide the features of reflection quicker and easier and one that didn't need
to be wrapped in a try{}catch{}. Something like this:
- https://gist.github.com/mikeschinkel/78684d708358e1d101e319c7a2fdef9c
But this being PHP — with its love of verbosity and complexity when adding
classes, and disdain for adding something if a capability already exists, no
matter how cumbersome it is — chances of this becoming a thing is pretty much
moot. So I am just pontificating.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
