Re: RFC [Discussion]: Closure self-reference
| From: | Stephen Reay | Date: | Fri, 09 Jun 2023 05:59:27 +0000 |
| Subject: | Re: RFC [Discussion]: Closure self-reference | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120550@lists.php.net to get a copy of this message | ||
> On 4 Jun 2023, at 02:11, Dan Ackroyd <Danack@basereality.com> wrote:
>
> Hi internals,
>
> I'm now opening the discussion for the Closure self-reference RFC:
> https://wiki.php.net/rfc/closure_self_reference
>
> This was previously discussed as a draft here:
> https://externals.io/message/112216#112216
>
> Thank-you to KapitanOczywisty for the implementation.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Hi Dan,
I quite like this idea, but, to (ab)use the analogy, the syntax bike shed definitely needs a few
more sample tins.
The various syntax choices that introduce a new variable all seem like they can easily lead to
developer confusion about where each of the two variables are actually defined and what is valid.. I
can see plenty of “$closure = fn() as $closure => ….;` just because people are unsure.
Is there a syntax issue with e.g.
fn::self / function::self for this? I
realise this is mostly just a variation on Closure::current() but it “feels” a bit
more natural, and has the added benefit that it *could* be extended to return a closure of **any**
function, including regular named methods/functions etc in a later RFC, if there’s demand for it.
Cheers
Stephen