On Tue, Feb 11, 2020, at 9:27 AM, Levi Morrison via internals wrote:
> I have three immediate thoughts:
> 1. It should be `fn` or `function`; reserving a new word even if it's
> contextual is pointless here.
> 2. It should support methods.
> 3. It should return a closure, not a string. The reason is for
> consistency with methods, where we want to capture the scope at the
> time the closure is created, not ran. Imagine passing a private method
> as a callback; if it was done via `[$obj, 'privatemethod']` then it
> will fail at runtime, because the scope it's called in doesn't have
I would love a nicer way to reference function names; it's really ugly to do functional code in PHP otherwise, or even just dynamic function logic within a namespace. If I never have to write $fn = __NAMESPACE__ . '\a_func' again, it will be too soon. :-)
I agree with Levi on points 2 and 3, for reasons already stated.
For bikeshedding on the syntax to use, I defer to the engine authors who can say what is possible to implement. However, the guideline should be *short*. If we make referencing a function too verbose, no one will want to use it and readability will be harmed. Double-whammy. That's why I'd say adding ten characters (::function) is a definite no-no.
::fn would work. There was previous discussion of ::name, which could then also apply to classes and objects. That would be acceptable, I think.
Other alternatives like &(funName) et al are also fine if they actually work; Again, I defer to the implementers on that.
But in general, yes please!