Re: [PHP-DEV] [RFC]

This is only part of a thread. view whole thread
  108486
February 11, 2020 15:27 internals@lists.php.net ("Levi Morrison via internals")
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.
  108487
February 11, 2020 16:39 manuelcanga@gmail.com (Manuel Canga)
On Tue, 11 Feb 2020 at 16:27, Levi Morrison morrison@datadoghq.com>
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.
Hi, Levi, 1. Yes 2. Yes, I agree 3. Wouldn't it be the opposite?. E.g: class Foo { static function run_callable(callable $callable) { $callable(); } private static function private_function() { echo "bar"; } } Foo::run_callable( [ 'Foo', 'private_function' ] ); Currently, this is valid. However, the following is fatal: class Foo { static function run_callable(callable $callable) { $callable(); } private static function private_function() { echo "bar"; } } Foo::run_callable(Closure::fromCallable(['Foo', 'private_function'])); The same with functions. If "::function" would retrieve a closure, some code could breaking when people switch string function syntax( e.g: 'strlen' ) to "::function" syntax( strlen::function ). On other hand, other option is ::callable, This is different to ::function, because it would affect to other callables, so that, returns could be other( Closure )
  108494
February 11, 2020 18:46 larry@garfieldtech.com ("Larry Garfield")
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
  108610
February 15, 2020 23:19 d.h.j.takken@freedom.nl (Dik Takken)
On 11-02-2020 16:27, 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.
Note that even though these do not introduce a new keyword it does mean that either of these would need to become reserved class constant names just like 'class'. Otherwise foo::fn or foo::function is ambiguous when both a function and a class named 'foo' are in scope. Regards, Dik Takken