2021-03-26 17:11 GMT+01:00, Mike Schinkel <m...@newclarity.net>:
>> On Mar 26, 2021, at 8:12 AM, Olle Härstedt <olleharst...@gmail.com>
>> wrote:
>>
>> 2021-03-26 3:38 GMT+01:00, Mike Schinkel <m...@newclarity.net>:
>>>
>>>
>>>> On Mar 25, 2021, at 4:09 PM, Olle Härstedt <olleharst...@gmail.com>
>>>> wrote:
>>>>
>>>> 2021-03-25 17:49 GMT+01:00, Mike Schinkel <m...@newclarity.net>:
>>>>>> On Mar 25, 2021, at 11:22 AM, Olle Härstedt <olleharst...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> 2021-03-25 16:02 GMT+01:00, Mike Schinkel <m...@newclarity.net>:
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 25, 2021, at 10:41 AM, Rowan Tommins
>>>>>>>> <rowan.coll...@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 *— 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
>>>>>>>> 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...
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>> 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,
>>>>>>>> we
>>>>>>>> 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
>>> vertical
>>> split screen in our editors — 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.
>>
>> 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.
>
> Unless I misunderstand the RFC, the closure would only auto-capture the
> variables that are specifically referenced inside the closure, so I don't
> see it capturing *all* variables unless the developer intended it to by
> referencing each one of them explicitly.
>
> And since the RFC captures the variables by-value I don't see how
> auto-capture would be any different than using "use (...)," even with
> objects.
Oh yeah, good point. My argument is moot.
Olle
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
