Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113764
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
In-Reply-To: <734f12de-da98-6b76-c2fe-8682f4d177aa@gmail.com>
Date: Thu, 25 Mar 2021 08:44:25 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <C82F07E9-696C-4B7B-B077-62F0CA88AB1A@newclarity.net>
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>
 <605bae82.1c69fb81.f49f7.d11eSMTPIN_ADDED_MISSING@mx.google.com>
 <919e30e7-3e5e-d955-7bb4-1e1b5825cdd1@gmail.com>
 <635DD146-FC6F-4991-8D2C-5A6B492722D5@newclarity.net>
 <734f12de-da98-6b76-c2fe-8682f4d177aa@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and
 shortfunctions take 2
From: mike@newclarity.net (Mike Schinkel)

> On Mar 25, 2021, at 5:28 AM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 25/03/2021 04:12, Mike Schinkel wrote:
>=20
>> Actually, there is a way to declare a local variable.  Use the long =
function syntax instead as there is no proposal to deprecate it.
>=20
> That's not quite what I meant. I meant that you can't say "capture by =
default, but this variable is definitely local".


Yes I can see you want a way to declare a local in an auto-capturing =
fn(), but respectfully I do not see why using the function() syntax is =
not a viable alternate solution when and if you want to explicitly not =
capture a variable.

I said "want" because you will never *need* to as you can always use a =
variable name that is not in the outer scope.=20

And yes I know, someone may come along later and add a named variable in =
the outer scope that matches your implicit local variable's name and =
potentially break your code, but again if that is a concern why can't =
you just use function() instead of fn()?  And wouldn't they actually be =
breaking their code (the outer code) if they did this?

Respectfully, you seem to be calling out a problem for which there is a =
tailor-designed solution explicitly recommended in the RFC. How can =
function() not address your stated concern?


> I'm guessing maybe "$foo =3D null;" at the top of the function would =
stop it auto-capturing, but the semantics of what exactly gets captured =
aren't spelled out in the RFC. That really needs to be added IMO.
>=20
>=20
>> Instead of using array_filter() with a side-effect free closure, I =
use a for loop because it is easier to reason about visually.
>=20
> Is that a bad thing? In many cases it's probably more efficient, and =
easier to read.


Depends on what your priorities are.  If you priorities are coding in =
the absolute most efficient manner and/or with the most clarity, no it =
is probably not a bad thing.

But if your priorities are coding in the most robust manner where your =
code is free from side-effects by design =E2=80=94 in a functional style =
=E2=80=94  and the performance difference is insignificant, then yes it =
is a bad thing.=20

And at least one of the pair of RFCs spell out this motivation to allow =
for more functional style explicitly.=20


>> It is not clear to me from reading the PEP how a "with" statement =
obviates the benefit of variable auto-capture? Maybe because I don't =
"think" in Python, so from reading their examples I cannot see how this =
relates?
>=20
> I didn't mean to say that the "with" statement would replace closures =
in general, but it would make them unnecessary *for some specific use =
cases*.


Respectfully again, to argue a use-case could be addressed in a =
different way than proposed by the RFC when that different way uses a =
hypothetical language feature that AFAIK does not have an RFC currently =
under consideration rings hollow to me.

Minimally I would expect you to at least first float the hypothetical on =
the list to see if there is appetite for it rather than just using is =
idea to snipe at an RFC that many people appear to support.


> You mentioned:
>=20
> > prime examples are database transactions and using throw-aware =
buffering handlers.


Actually, I did not provide that example. Other people did. =20

What I stated was I had other use-cases that concerned me more than =
transactions, which I already explained in my email.=20

However, in no way do I mean to argue against their value for other =
developers who mentioned them.


> If your current code looks something like this:
>=20
> wrap_in_buffer(function($transaction) use ($to, $library, $thread, =
$author, $title, $library_name, $top_post) {
>     doSomething($to, $library, $thread);
>     andThenSomethingElse($author, $title, $library_name, $top_post);
> });
>=20
> That's a perfect use case for a Context Manager:
>=20
> with ( wrap_in_buffer() ) {
>     doSomething($to, $library, $thread);
>     andThenSomethingElse($author, $title, $library_name, $top_post);
> }
>=20
> There's no callback, so no need to capture anything, and the =
implementation of all the try-catch-finally logic would be baked into =
the language, so the implementation of wrap_in_buffer() would also be =
much simpler.


But thanks for clarifying with examples, because I did ask for that.

That said, "with" is still hypothetical.  Are you planning to champion =
its inclusion into PHP with a discussion and then follow up RFC?

-Mike=