> 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.
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().
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.
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 (...) {...}."
>>
>> 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.)
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 — not that it matters — and it comes down to what
those who actually get a vote think.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
