Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120527
MIME-Version: 1.0
References: <CA+kxMuTTuk8rQhdAFqkUDmyP95F0dSYmZMUyD0NY4Ae+CPL0PA@mail.gmail.com>
 <647C701E.8030104@adviesenzo.nl>
In-Reply-To: <647C701E.8030104@adviesenzo.nl>
Date: Sun, 4 Jun 2023 23:42:26 +0100
Message-ID: <CA+p1FabNYtzmyhjGkp2KMk3BO2YnDU1hYTf3ps7UXzefTKt_Ng@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000dcf55d05fd5580b0"
Subject: Re: [PHP-DEV] RFC [Discussion]: Closure self-reference
From: davidgebler@gmail.com (David Gebler)

--000000000000dcf55d05fd5580b0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 4, 2023 at 12:06=E2=80=AFPM Juliette Reinders Folmer <
php-internals_nospam@adviesenzo.nl> wrote:

> When I read the RFC, I keep wondering why new syntax is needed for this.
> Isn't this a solved problem with the solution being "use a named function=
"
> ?
>

I think that's a bit harsh - couldn't we say that about any limitation of
closures, or any proposed improvement to closure handling? "Just use a
named function" doesn't seem like a fair critique when the usefulness of
closures isn't in question, or the fact that people do use closures.


> Might I suggest to expand the RFC to answer all or at least some of the
> below questions ?
> * Why is a recursive function call something which should be supported
> at the language level for closures ?
>

It seems a reasonable expectation that the functional capability of
closures should as closely match named functions as possible, doesn't it?
Or at least that whatever limitations they have don't lead to runtime
surprises like the example given in the RFC.


> As for the syntax choice: it seems like the proposed choice is largely
> arbitrary and personal to the authors to go for a "languagesy" syntax.
> * Was any research done on how frequently this is expected to be used ?
> * If so, does that frequency justify the need for a change at the
> language level ?
> * Was any research done to find out syntax preferences from anyone other
> than the authors ?

* Was the impact of introducing (yet another) syntax level change on
> static analysis tools considered ?
>

I think there was a fair bit of discussion about syntax choice in the
previous thread (which was a long time ago now) but the point about impact
on static analysis tools is valid and relevant. That said, there is an
argument that it's for ecosystem tools to adapt to changes in the language,
not for the language to orient itself to the convenience of those tools.

Still, I suppose we do have a special case with static analysis tools in
particular over other stock userland libraries, because these tools in
particular serve to fill gaps in PHP's limitations as a dynamic language,
so I think your point about reconsidering syntax choice in respect of
making adaptation easier is worth the RFC authors considering further.

I think for users, the proposed choice with the "as" keyword is the most
natural. A recursive closure is probably an extremely rare thing to do
whatever way you cut it, though, so if the syntax for users is a little
uglier but it makes some other aspect such as what you've raised above
easier, I can see the justification for choosing one of the other options,
probably a constant like __CLOSURE__.

Anyway, although I can't vote, +1 from me in principle on the feature,
syntax TBC. It closes a very small gap but a gap all the same.

-Dave

--000000000000dcf55d05fd5580b0--