Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108494
User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1
Mime-Version: 1.0
Message-ID: <0c6f16a8-a6f1-4adf-9264-a23300bbe2c7@www.fastmail.com>
In-Reply-To: 
 <CAAKU0u=mVa7VJhANmSX7S4D2KXwHXUysaCw2_Fo9KHiuCviuiA@mail.gmail.com>
References: 
 <CAD5P3=JwFK03L-DWJYaa0dbBj1chbef_=K-vyawLNeoAz7dHjA@mail.gmail.com>
 <CAAKU0u=mVa7VJhANmSX7S4D2KXwHXUysaCw2_Fo9KHiuCviuiA@mail.gmail.com>
Date: Tue, 11 Feb 2020 12:46:12 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC]
From: 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