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).
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. 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?
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.
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]".
> 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
See above. (I have no voting power.)
Olle
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
