On Tue, 6 Oct 2020 at 11:28, G. P. B. <george.bany...@gmail.com> wrote:
> 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
>
Ressending to the list as I seem to have messed up my reply.
