First, can you please bottom-post and not top-post.
On Tue, 6 Oct 2020 at 09:53, Brent Roose <bre...@stitcher.io> wrote:
> Hi internals
>
> The reason multi-line short closures are so valued by userland devs is
> because they are shorter to write and prettier to read. While some of us
> might not agree on the definition of "prettier to read", it was one of the
> key arguments for adding short closures in the first place:
>
> > Anonymous functions in PHP can be quite verbose, even when they only
> perform a simple operation. Partly this is due to a large amount of
> syntactic boilerplate, and partly due to the need to manually import used
> variables. This makes code using simple closures hard to read and
> understand. This RFC proposes a more concise syntax for this pattern. [1]
> >
>
> We can have the discussion again on whether we like short closures or not,
> but it turned out most of internals _and_ userland devs do — based on the
> vote count in the sigle line RFC and the reaction on Nuno's PR, as well as
> my experience from an OSS maintainer point of view.
>
I didn't know we were meant to do code golfing with production code, might
have missed a memo somewhere.
> Furthermore, the `use(*)` syntax misses the point of this proposal: it's
> not about being able to use all variables from the outer scope,
If it's not about being able to use all variables (or even just one that is
irrelevant) from the outer scope, then what is the point?
Saving 6 characters by only writing fn() {} instead of function {}?
> it's about a clean syntax that's as short as possible — even when you
> personally disagree that it is. I've made the same argument before on this
> list: it's clear that the PHP community _wants_ these changes:
Wanting something isn't an argument. Looking at what part of the community
wants, we should be using @ for attributes.
named arguments, property promotions, short closures, … these are all
> features that aren't _necessary_, still they are great features of a
> modern-day language.
>
Obviously nothing is necessary, we could write assembler style with only
goto statements.
I also want to quote from Larry Garfields book on thinking functionally in
> PHP [2], to demonstrate the signicant impact short closures already had
> today:
>
> > “Combined with PHP’s overall clunky syntax for doing functional-esque
> code, I generally didn’t go further than “pure functions are your friend,”
> either in my own code or what I explained to others.
> >
> > That is, until PHP 7.4.
> >
> > PHP 7.4’s introduction of short lambdas is, as we’ll see in this book, a
> game-changer. While it doesn’t make anything new possible, it makes a lot
> of things suddenly practical. That makes all the difference, so I decided
> it was time to buckle down and really dig into functional programming.”
>
> Larry continues to write a whole book about functional programming in PHP,
> and short closures play a significant role.
>
Finally a resemblance of an actual argument.
> So I hope to see more input on Nuno's PR from a techinical point of view:
> what's missing, what's needed to get this to the RFC phase, … and not only
> discussions about what syntax we like or not, or whether there are other
> ways to solve the same problem. Please provide Nuno with actionable
> feedback.
>
> Kind regards
> Brent
>
> [1] https://wiki.php.net/rfc/arrow_functions_v2 <
> https://wiki.php.net/rfc/arrow_functions_v2>
> [2] https://leanpub.com/thinking-functionally-in-php <
> https://leanpub.com/thinking-functionally-in-php>
>
Jokes aside, the actionable feedback is to argue *why* auto capture of the
outer scope should be added to the
language as "it is very not PHP" a direct quote from Rasmus from his talk
"25 years of PHP" [1] and from the
same section one of the reasons why people don't mind the current single
line expression form is because it
doesn't look like a new scope.
As Rowan said in his analysis changing this specific behaviour of scope
being able to "leak" into another one
needs a lot of justification, the current short closure syntax doesn't even
use braces {} which are the de facto
signal in PHP that you are entering in a new scope.
Going back to the `use(*)` syntax: the reason why people propose this
extension (which is not mutually exclusive
with adding support for fn {} without outer scope capture, albeit strange)
is that it is more in PHP traditional design
philosophy. You can argue against this syntax and in favour of Nuno's, but
again it is NOT missing the point.
Moreover, Larry has also made a PR which extends short closures [2] in a
way I personally find way more appealing.
Regards
George P. Banyard
[1] https://youtu.be/Qa_xVjTiOUw?t=1895
[2] https://github.com/php/php-src/pull/6221
