Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120519
To: internals@lists.php.net
References: <CA+kxMuTTuk8rQhdAFqkUDmyP95F0dSYmZMUyD0NY4Ae+CPL0PA@mail.gmail.com>
Message-ID: <647C701E.8030104@adviesenzo.nl>
Date: Sun, 4 Jun 2023 13:06:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CA+kxMuTTuk8rQhdAFqkUDmyP95F0dSYmZMUyD0NY4Ae+CPL0PA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------040403000504010000050105"
Subject: Re: [PHP-DEV] RFC [Discussion]: Closure self-reference
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------040403000504010000050105
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 3-6-2023 21:11, Dan Ackroyd 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
>

Hi Dan,

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" ?

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 ?
* Was the pre-existing syntax available to solve this - named functions 
- considered ?
* Why is using named functions not considered a valid solution by the 
RFC proposers ?

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 ?
     As a co-maintainer of a static analysis tool, I would have a strong 
preference for either `__CLOSURE__` or a static function on the Closure 
class as that would make the syntax "isolated" to this change, while an 
`as $fn` syntax change would mean that any analysis of the `as` keyword 
and a lot of analysis of variables will need to be adjusted to allow for 
this new syntax.
     Not necessarily a reason to change the proposal, but possibly 
something to consider.

Either way, my two pennies for whatever they are worth.

Smile,
Juliette


--------------040403000504010000050105--