Re: [RFC]

> On Feb 13, 2020, at 2:33 AM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > On 13 February 2020 03:33:32 GMT+00:00, Mike Schinkel <mike@newclarity.net> wrote: >>> On Feb 12, 2020, at 5:47 PM, Rowan Tommins <rowan.collins@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