Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113784
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: <CAJpLVh0ihALcqdGOCeKQ7DDXTHqOvoSW1K2SDO=VEtaJUab7zA@mail.gmail.com>
Date: Thu, 25 Mar 2021 12:49:30 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <15AE4315-A456-4ED8-990A-49EBD76C5B46@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>
 <CALZWoqXZF9wegVGwGMjjVEV89zTjb-TYS87MqP36fSk-qJqD4g@mail.gmail.com>
 <daffe9ec-3163-25cc-bb52-587fbd2230bb@gmail.com>
 <36E45DD6-E2BD-4801-BAAE-4355C83D1AC3@newclarity.net>
 <CAJpLVh0ihALcqdGOCeKQ7DDXTHqOvoSW1K2SDO=VEtaJUab7zA@mail.gmail.com>
To: =?utf-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@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 11:22 AM, Olle H=C3=A4rstedt =
<olleharstedt@gmail.com> wrote:
>=20
> 2021-03-25 16:02 GMT+01:00, Mike Schinkel <mike@newclarity.net>:
>>=20
>>=20
>>> On Mar 25, 2021, at 10:41 AM, Rowan Tommins =
<rowan.collins@gmail.com>
>>> wrote:
>>>=20
>>> On 25/03/2021 12:31, Nuno Maduro wrote:
>>>=20
>>>> The reason why we believe the vast majority of PHP Developers are =
going
>>>> to
>>>> appreciate this RFC is because multi-line short closures (aka
>>>> Auto-capturing multi-statement closures) *are more simple, shorter =
to
>>>> write, and prettier to read *=E2=80=94 and the community love these =
changes as
>>>> proven on "property promotions", "one-line short closures", etc.
>>>=20
>>>=20
>>> My main point was that the RFC needs to spell out this argument, =
rather
>>> than taking it for granted that everyone agrees on "those situations =
where
>>> that is warranted".
>>>=20
>>> Most of the current text should be summarised in a "syntax choices"
>>> section somewhere near the end. I would like to see much more space
>>> devoted to:
>>>=20
>>> * Why we need this feature. What has changed since it was left out =
of the
>>> arrow functions RFC? What problems is it addressing? Why do you =
think it
>>> is the best approach to those problems?
>>> * The exact semantics proposed: How will the variables to be =
captured be
>>> determined? Will it distinguish variables which are written before =
they're
>>> read, and if so how is that defined? Can auto-capturing closures be
>>> nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a =
from the
>>> outermost scope? And so on...
>>>=20
>>>=20
>>>> Besides, one advantage of this RFC is that it is consistent with =
the
>>>> current syntax of the language and with the short-functions RFC[2]. =
For
>>>> example, by proposing that "fn" keyword indicates a function will
>>>> auto-capture variables, by value.
>>>=20
>>>=20
>>> While it's a cute rationalisation, there's no intuitive reason why =
"fn"
>>> should have that meaning; we could pick any aspect of the current =
arrow
>>> function syntax and say "the 'fn' keyword means that".
>>>=20
>>>=20
>>>=20
>>>> On the other hand "use (*)" has no usages / or current meaning in =
the
>>>> language.
>>>=20
>>>=20
>>> This is a straw man argument. I could equally say that "fn() { } has =
no
>>> usages or current meaning in the language" - of course it doesn't, =
we
>>> haven't added it yet!
>>>=20
>>> The "function use() {}" part of "function use(*) {}" has a
>>> well-established meaning, and "*" to mean "everything" is a notation
>>> developers are likely to be very familiar with.
>>>=20
>>> The two disadvantages I see with using "fn" as proposed are:
>>>=20
>>> * Because it's shorter, people will decide it's the "better" =
version, when
>>> they don't actually need any variable capture. An explicit syntax =
like
>>> "use(*)" instead makes this a deliberate choice.
>>=20
>> And yet adding " use (*)" makes the syntax longer, which goes against =
one of
>> the goals many people have for it: to be shorter.
>=20
> I don't understand why this is a target in the first place. Shorter
> does not mean more readable, and readable is more important than
> writable.

I agree that readable is more important than writable, but shorter also =
does not necessarily mean it is *less* readable, either. =20

For some people, shorter makes it more readable because there is less to =
read and more whitespace surrounding it. Ironically readability is why I =
prefer fn() w/autocapture over "function(...) use (...) {...}."

Also, it appears you may be discounting that readablity evolves as =
people's familiarity with a new syntax increases.  For example, I found =
RegEx completely unreadable for a long time, but today I find them =
completely readable because I now understand them. Have you already =
considered whether or not you would still find fn() w/autocapture less =
readable even after you have more time and experience seeing it in other =
people's code, and decided that you would still find it less readable?

I do recognize that ever developer has their own preference and I am =
sensing that your preference is for more verbose syntax, at least in =
this case? If that is true shouldn't you just state that more verbose is =
your preference and if you have a vote then vote against the RFC? Isn't =
it unfair to implictly assert that "shorter is less readable" when =
really it is just a preference?

-Mike