Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113797
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: <CAJpLVh0PTjXY3ov2-XppYBR3Z4eskhMQx9xUB7egVwy0nRiFpw@mail.gmail.com>
Date: Thu, 25 Mar 2021 22:38:44 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <BD2A7A81-C3F7-4738-8237-25B6FB776C3F@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>
 <15AE4315-A456-4ED8-990A-49EBD76C5B46@newclarity.net>
 <CAJpLVh0PTjXY3ov2-XppYBR3Z4eskhMQx9xUB7egVwy0nRiFpw@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 4:09 PM, Olle H=C3=A4rstedt =
<olleharstedt@gmail.com> wrote:
>=20
> 2021-03-25 17:49 GMT+01:00, Mike Schinkel <mike@newclarity.net>:
>>> 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.
>>=20
>> I agree that readable is more important than writable, but shorter =
also does
>> not necessarily mean it is *less* readable, either.
>=20
> Sure. The brain removes noise and reads in "symbols" anyway (where
> "fn" or "function" is a symbol of size 1).

That is actually not exactly true, at least not in all cases.=20

When "nction" combined with " use (.....)" adds to line length such that =
a developer must scroll horizontally to see all the text then it is not =
the same.=20

And this is not a hypothetical for those of us who frequently use =
vertical split screen in our editors =E2=80=94 I am constantly battling =
with lines that are too long.

Also when longer lines cause code to wrap on GitHub or in blog posts or =
other places then it is not the same.

> A more important aspect of readability is the cognitive load on
> short-term memory, or how many "chunks" the programmer has to keep in
> memory to understand a piece of code. In this case, I think
> immutability and local scope helps a lot, of which PHP has neither. Or
> maybe predictability of the scope? All language quirks hurt
> readability. I never had a problem with scope in JS, despite it
> lacking immutability and only recently got proper block scope.

Given that the RFC prescribes by-value capture and not by-ref capture =
how it is really even a problem?  Or are you arguing that you fear =
people will just write closures hundreds of lines long?

Maybe PHP should deprecate functions longer than 50 or 100 lines?  =
<rhetorical question>

> Maybe more important than explicit/implicit capturing of scope is to
> keep your functions short...? In our legacy code-base, we have =
functions
> thousands of lines long. I can see auto-capturing being a problem
> there, but that's because of the technical debt and not the feature
> itself, I guess. Will our juniors realize that, tho?

Now here is where I think the real problem is, the fact that other =
developers write functions thousands of lines long.

But realistically, legacy code won't be affected as people are rarely if =
ever going to go back to your legacy code and convert a thousand line =
function into a closure with auto-capture.

OTOH if they maintain the code by adding an auto-capture fn() closure =
then are they really likely to add a closure hundreds of lines long?

And if they do, don't you really have a much bigger problem than =
auto-capturing of closure variables, e.g. should you not be either =
educating these programmers or hiring better ones?

> Never the less, the need to include 5+ variables in your closure -
> code smell? I stated above that command pattern and data-transfer
> objects are probably better, and that's why I think the example in the
> RFC is not motivating enough.

Now that I fully agree with.  My use-cases for auto-capture closures are =
typically only a few lines long, inside a function with only a few lines =
and a few variables to capture, and have only one or two variables in =
the use(). =20

OTOH, I would not want to deny people the ability to reference many =
variables because they may have use-cases where that rule-of-thumb being =
a code smell is not valid.

> The question is not "what do I want to be able to write", but rather
> "what do I want to be forced to read [by less qualified programmers]".

By the same token I would really rather not have to read =
try{...}catch{...} logic, but I know that using that construct is =
something many programmers prefer.=20

So I accept that not everyone thinks like I do and that I will have to =
read and understand code that is not what I consider ideal from time to =
time. Maybe you can come to the same acceptance for auto-capture in =
multi-line fn()s?

> 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 (...) {...}."
>>=20
>> 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?
>>=20
>> 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?
>>=20
>> -Mike
>=20
> See above. (I have no voting power.)

Well, you and I are in the same boat there.

So in summary, you do not like the RFC and I do. That means our two =
non-voting block cancels each other out =E2=80=94 not that it matters =
=E2=80=94 and it comes down to what those who actually get a vote think.

-Mike=