Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112012
MIME-Version: 1.0
References: <CALZWoqU_qQQiQ5O6Pa8Upxo2FYZ2hpMA0dy9=CZndeEFsijgxA@mail.gmail.com>
 <446c9894-191f-e53b-4534-31c4e7b91d7b@gmail.com> <881e2335-5f81-0d79-6a17-06bc20f14223@gmx.net>
 <CADK1yX+0EDTuZ2Sg20_xJH02zLC15Ks1jcYR5zfECdnUBsfUFQ@mail.gmail.com>
 <873361ff-02c8-b9df-9b7a-c9e89e25a880@gmx.net> <7F014A40-2D47-4DA6-8A38-59518218F9CA@stitcher.io>
 <CAFPFaMKSVuWp9ZmdUQavE6vT=qokZpBfmrMc9=Wkot=r5fiJHA@mail.gmail.com>
In-Reply-To: <CAFPFaMKSVuWp9ZmdUQavE6vT=qokZpBfmrMc9=Wkot=r5fiJHA@mail.gmail.com>
Date: Tue, 6 Oct 2020 11:29:29 +0100
Message-ID: <CAFPFaMLF+mdPMF0FdkzUTUQy822-ApYAsiArxAQDaiehUpcdWw@mail.gmail.com>
To: Brent Roose <brendt@stitcher.io>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a1038a05b0fe1377"
Subject: Re: [PHP-DEV] RFC: Support for multi-line arrow functions
From: george.banyard@gmail.com ("G. P. B.")

--000000000000a1038a05b0fe1377
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 6 Oct 2020 at 11:28, G. P. B. <george.banyard@gmail.com> wrote:

> First, can you please bottom-post and not top-post.
>
> On Tue, 6 Oct 2020 at 09:53, Brent Roose <brendt@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 t=
he
>> 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 use=
d
>> 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 =E2=80=
=94 based on
>> the vote count in the sigle line RFC and the reaction on Nuno's PR, as w=
ell
>> as my experience from an OSS maintainer point of view.
>>
>
> I didn't know we were meant to do code golfing with production code, migh=
t
> 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 =E2=80=94 even whe=
n you
>> personally disagree that it is. I've made the same argument before on th=
is
>> list: it's clear that the PHP community _wants_ these changes:
>
>
> Wanting something isn't an argument. Looking at what part of the communit=
y
> wants, we should be using @ for attributes.
>
> named arguments, property promotions, short closures, =E2=80=A6 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 i=
n
>> PHP [2], to demonstrate the signicant impact short closures already had
>> today:
>>
>> > =E2=80=9CCombined with PHP=E2=80=99s overall clunky syntax for doing f=
unctional-esque
>> code, I generally didn=E2=80=99t go further than =E2=80=9Cpure functions=
 are your friend,=E2=80=9D
>> either in my own code or what I explained to others.
>> >
>> > That is, until PHP 7.4.
>> >
>> > PHP 7.4=E2=80=99s introduction of short lambdas is, as we=E2=80=99ll s=
ee in this book,
>> a game-changer. While it doesn=E2=80=99t make anything new possible, it =
makes a lot
>> of things suddenly practical. That makes all the difference, so I decide=
d
>> it was time to buckle down and really dig into functional programming.=
=E2=80=9D
>>
>> 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, =E2=80=A6 an=
d 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 th=
e
> 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, bu=
t
> 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=3D1895
> [2] https://github.com/php/php-src/pull/6221
>

Ressending to the list as I seem to have messed up my reply.

--000000000000a1038a05b0fe1377--