> On Feb 13, 2020, at 2:33 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> On 13 February 2020 03:33:32 GMT+00:00, Mike Schinkel <m...@newclarity.net>
> wrote:
>>> On Feb 12, 2020, at 5:47 PM, Rowan Tommins <rowan.coll...@gmail.com>
>> 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?
>
>
> I never said it would; the intent of this example was to show what is
> possible in current PHP, in response to your comment about returning a
> closure being "a feature we already have".
> The key new feature being proposed is a way to resolve an unqualified
> function name based on current namespace and imports, without calling the
> function. The open question is whether the result of that should be expressed
> as a string or as a Closure object, but in current PHP the feature doesn't
> exist at all.
Let me clarify for you what I was trying to say.
1. IF foo::function returns a name string THEN using Closure::fromCallable(
foo::function ) can provide a closure.
2. IF foo::function returns a closure THEN how to we get the name string?
Hence we already have a way to get the closure _if_ ::function returns a name
string, but we would *not* have a way to get the name string if ::function
returns a closure.
IOW, we can already derive a closure if we have a name, but we cannot derive a
name if we have a closure.
I hope this clarifies what I was trying to say when I said "we already have it."
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
