Rowan,
I've just added a few more tests with the exact examples you have presented
in this mail list:
https://github.com/php/php-src/pull/6246/commits/c3a50d671c5d8fa4b775ec67fe77d0cbd5cc8030
.
On Fri, 26 Mar 2021 at 16:48, Olle Härstedt <olleharst...@gmail.com> wrote:
> 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
>
>
