Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113748
MIME-Version: 1.0
References: <88c9eb5f-f80c-4869-b7f8-1b58b9e2eaa3@www.fastmail.com>
 <CAF+90c9PRmK1FM_uUO3qMhhvMybY4z_aZkmMO53TVfuy--U32g@mail.gmail.com>
 <CAPKYkKxTgHnzXKwkHi4qgJewY86vWFehrhN39fyrrK5KWNVvig@mail.gmail.com>
 <4DC3B66E-A91A-4AA9-8872-8EE9DE92C2D4@cschneid.com> <8c72c162-83c0-7c7f-2fa7-4fbe3fb30a4a@gmail.com>
 <605bae7f.1c69fb81.7d28d.c115SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <605bae7f.1c69fb81.7d28d.c115SMTPIN_ADDED_MISSING@mx.google.com>
Date: Wed, 24 Mar 2021 17:45:45 -0400
Message-ID: <CAPKYkKwA7yTheAUvVZWwv3S0eebtEEjb7-VuKdZmFBL8WCfRVA@mail.gmail.com>
To: Mark Randall <marandall@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004e793805be4f39b0"
Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and
 shortfunctions take 2
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000004e793805be4f39b0
Content-Type: text/plain; charset="UTF-8"

On Wed, Mar 24, 2021 at 5:26 PM Mark Randall <marandall@php.net> wrote:

> On 24/03/2021 21:00, Rowan Tommins wrote:
> > As Christian says, automatic capture is a dramatic change to the
> > language's scoping rules, and IMHO requires a more thorough
> > justification on why the current syntax is burdensome. As I've said
> > previously, my naive impression is that a long list of captured
> > variables ought to be as bad a code smell as a long list of parameters;
> > I'm willing to be proven wrong on this, but nobody has yet stepped
> > forward with a real-life example.
>
> Automatic capture ceased to be a dramatic change from PHP the day after
> short closurers were introduced. So they've been a part of PHP for years
> now.
>
> I hit long lists of use() repeatedly, almost always because I need to
> perform a series of operations within a callback, prime examples are
> database transactions and using throw-aware buffering handlers.
>

DB transaction is one place I have a long list of use parameters as well.
Since the goal is to do as much before we start the transaction as
possible, I always end up with a lot of variables resulting from that prep
work that I need to utilize inside the transaction callback.  My gut tells
me the use-cases for long use lists that don't indicate code smell are
pretty small though.



> In general, anything that needs to wrap a code block in a complex set of
> instructions before and after.
>
> To give my own example, earlier this week I wrote the following:
>
> $x = function () use ($to, $library, $thread, $author, $title,
> $library_name, $top_post) { ... }
>
> That was just to get those variables inside a callback that could be
> invoked inside a throw-aware buffering helper.
>
> I believe that by explicitly stating my intent to use auto capture by
> using fn() { ... } that my code would have been cleaner with less noise.
>
> If I thought otherwise, I would be under no obligation to use them and
> could use function() { ... } instead.
>

I agree. I think as long as we make it clear to users that function() does
not provide auto capture, but fn() does, we're fine. In the same way that
JavaScript make it clear that function(){} changes the meaning of "this"
while () => {} does not. The fact that they behave differently like that is
great in my opinion. I use function(){} when I want the changed context
(like event listener callbacks) and () => {} when I know I only need access
to the parent context and don't care about any possible redefinition.


>
> For me auto capture is a solid +1.
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepeeler@gmail.com

--0000000000004e793805be4f39b0--