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 > access.
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! --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
