Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113799
MIME-Version: 1.0
In-Reply-To: <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>
 <BD2A7A81-C3F7-4738-8237-25B6FB776C3F@newclarity.net>
Date: Fri, 26 Mar 2021 13:12:32 +0100
Message-ID: <CAJpLVh25PkPEomTjfXJpdGxRx6MhQBLL0JnHajJkaniOTSDtFQ@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and
 shortfunctions take 2
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2021-03-26 3:38 GMT+01:00, Mike Schinkel <mike@newclarity.net>:
>
>
>> On Mar 25, 2021, at 4:09 PM, Olle H=C3=A4rstedt <olleharstedt@gmail.com>
>> wrote:
>>
>> 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.c=
om>
>>>> wrote:
>>>>
>>>> 2021-03-25 16:02 GMT+01:00, Mike Schinkel <mike@newclarity.net>:
>>>>>
>>>>>
>>>>>> On Mar 25, 2021, at 10:41 AM, Rowan Tommins <rowan.collins@gmail.com=
>
>>>>>> wrote:
>>>>>>
>>>>>> On 25/03/2021 12:31, Nuno Maduro wrote:
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> 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".
>>>>>>
>>>>>> 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:
>>>>>>
>>>>>> * Why we need this feature. What has changed since it was left out o=
f
>>>>>> the
>>>>>> arrow functions RFC? What problems is it addressing? Why do you thin=
k
>>>>>> it
>>>>>> is the best approach to those problems?
>>>>>> * The exact semantics proposed: How will the variables to be capture=
d
>>>>>> 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 fro=
m
>>>>>> the
>>>>>> outermost scope? And so on...
>>>>>>
>>>>>>
>>>>>>> Besides, one advantage of this RFC is that it is consistent with th=
e
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> 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".
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On the other hand "use (*)" has no usages / or current meaning in
>>>>>>> the
>>>>>>> language.
>>>>>>
>>>>>>
>>>>>> 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, w=
e
>>>>>> haven't added it yet!
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> The two disadvantages I see with using "fn" as proposed are:
>>>>>>
>>>>>> * 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.
>>>>>
>>>>> And yet adding " use (*)" makes the syntax longer, which goes against
>>>>> one
>>>>> of
>>>>> the goals many people have for it: to be shorter.
>>>>
>>>> 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.
>>
>> 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.
>
> 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.
>
> And this is not a hypothetical for those of us who frequently use vertica=
l
> 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 j=
ust
> 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.

No, I'm more concerned that someone will add a closer at the *bottom*
of a long-ass function, capturing all variables, and then not have a
properly defined lifetime, causing a memory leak or "spooky action at
a distance" with object references. In other words, could it be a
foot-gun? Maybe far-fetched, I don't know.

Olle