Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117906
MIME-Version: 1.0
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com> <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com>
In-Reply-To: <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com>
Date: Sun, 12 Jun 2022 00:01:15 +0200
Message-ID: <CADK1yXJCQiDOZbTxpv8DLycA3wZkYPEP_bOGVH0BCRxWZgX92w@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c2f67505e13333aa"
Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
From: deleugyn@gmail.com (Deleu)

--000000000000c2f67505e13333aa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 11, 2022 at 11:14 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On 09/06/2022 17:34, Larry Garfield wrote:
> > Last year, Nuno Maduro and I put together an RFC for combining the
> multi-line capabilities of long-closures with the auto-capture compactnes=
s
> of short-closures ... Arnaud Le Blanc has now picked up the flag with an
> improved implementation ... The RFC has therefore been overhauled
> accordingly and is now ready for consideration.
> >
> > https://wiki.php.net/rfc/auto-capture-closure
>
>
> They may sound like the same thing, but to me "short closure syntax"
> (and a lot of the current RFC) implies that the new syntax is better for
> nearly all closures, and that once it is introduced, the old syntax
> would only really be there for compatibility - similar to how the []
> syntax replaces array() and list(). If that is the aim, it's not enough
> to assert that "the majority" of closures are very short; the syntax
> should stand up even when used for, say, a middleware handler in a
> micro-framework. As such, I think we need additional features to opt
> back out of capturing, and explicitly mark function- or block-scoped
> variables.
>

The RFC does mention that the existing Anonymous Function Syntax remains
untouched and will not be deprecated. Whether the new syntax is better for
nearly all closures will be a personal choice. If the new syntax doesn't
suit, say, a middleware handler, then we still can:
- reach for the old syntax
- use invocable classes
- call another method or function which creates a brand new scope and then
returns a function/callable.


>
> On the other hand, "auto-capturing" could be seen as a feature in its
> own right; something that users will opt into when it makes sense, while
> continuing to use explicit capture in others. If that is the aim, the
> proposed syntax is decidedly sub-optimal: to a new user, there is no
> obvious reason why "fn" and "function" should imply different semantics,
> or which one is which. A dedicated syntax such as use(*) or use(...)
> would be much clearer. We could even separately propose that "fn" and
> "function" be interchangeable everywhere, allowing combinations such as
> "fn() use(...) { return $x; }" and "function() =3D> $x;"
>

The previous discussions talked about use(*) or use(...) and most people I
know that would love this RFC to pass would also dislike that alternative.
It does not have the greatest asset for short closure: aesthetics. Maybe my
personal bubble is not statistically relevant, but this is where PHP
Internals is lacking on surveying actual users of the language to help on
such matters. All I can say is that use(*) is not a replacement for the RFC=
.


>
> To go back to the point about variable scope: right now, if you're in a
> function, all variables are scoped to that function. With a tiny handful
> of exceptions (e.g. superglobals), access to variables from any other
> scope is always explicit - via parameters, "global", "use", "$this", and
> so on. If we think that should change, we should make that decision
> explicitly, not treat it as a side-effect of syntax.
>

Any attempt to make it explicit defeats the purpose of the RFC. The
auto-capturing means we don't have to write awkward code to access
variables. The only way we have to avoid awkward syntax (such as use
($var1, $var2)) is to declare an entire new invocable class and send the
parameters via the constructor. When many variables are involved, that may
still be a great option, but doing that just for 1 variable and 2 lines is
quite... sad. When I think of new accessors for this particular case, they
would either be innovative or verbose. If they are verbose, we already have
a syntax for that. If they are innovative, it would be an awkward
out-of-place situation that doesn't happen elsewhere in the language. Or I
lack the imagination to see a different result.



Ultimately, I see fn() as "an opt-in to not create a separate scope for a
function". PHP has several language constructs that may or may not create a
separate scope.
Delimite Scope: function, method, class, procedural file
Shared scope: if, for, foreach, include, require and fn


> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--=20
Marco Aur=C3=A9lio Deleu

--000000000000c2f67505e13333aa--