Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117922
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361
Mime-Version: 1.0
Message-ID: <85cd3b46-379a-4f0e-b78d-3bd000a349e1@www.fastmail.com>
In-Reply-To: <25caf251-d9a4-ba57-9e23-7f0ccd914cf3@gmail.com>
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
 <2279cbd2-fcfe-460f-97f9-0029b7b043bb@www.fastmail.com>
 <25caf251-d9a4-ba57-9e23-7f0ccd914cf3@gmail.com>
Date: Sun, 12 Jun 2022 16:29:06 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Jun 12, 2022, at 3:44 PM, Rowan Tommins wrote:
> On 12/06/2022 18:21, Larry Garfield wrote:
>> The primary target of this RFC is people writing 2-4 line closures that import 1-2 variables
>
>
> The first half of that sentence I was expecting - although as I've 
> already said, I think the chosen syntax suggests strongly that the RFC 
> is really targeting *all* closures, not any subset of them.
>
> The second half makes much less sense. If you are only importing 1 or 2 
> variables, is writing their names really that big a burden?
>
> Several of the conversations I've had on this in the past have been very 
> explicitly about the burden of large numbers of captures; if that's 
> really as rare as you suggest, it makes me wonder why we're even bothering.
>
> Regards,

Disclaimer: My own view, I cannot speak for Nuno or Arnaud.

If you're capturing a very large number of variables, then I would view that as a code smell.  "Very large" is subjective, of course, and there's some context to it.

The two main use cases I see myself using are

A) 2-3 liners that use 1-3 variables from scope, so it's dead obvious what they are. In this case, the extra use clause doesn't really add much beyond visible noise.

B) An entire method body is a closure that is being returned, or inlined into an inTransction() call or something like that.  In this case, basically all method parameters would be captured, and it would be on the very previous line, so no matter how many there are (more than ~5 is probably a problem with the method, not with the closure), they're redundant and don't tell you anything that isn't already self-evident.

So the burden is in having to think about redundant syntax at all, plus having more redundant text that has to be read in the future.  Even with use(*) or use(...) or whatever, that's better than the status quo but is still just more boilerplate that would have to be added/removed when switching from a one line short lambda (side note: This is the term I always use; I basically never use "arrow function".  I don't know how typical that is) to a 2-line closure when refactoring.

--Larry Garfield