> 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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
