Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112011
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>
In-Reply-To: <7F014A40-2D47-4DA6-8A38-59518218F9CA@stitcher.io>
Date: Tue, 6 Oct 2020 11:28:10 +0100
Message-ID: <CAFPFaMKSVuWp9ZmdUQavE6vT=qokZpBfmrMc9=Wkot=r5fiJHA@mail.gmail.com>
To: Brent Roose <brendt@stitcher.io>
Cc: Levi Morrison via internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e66d9b05b0fe0eb8"
Subject: Re: [PHP-DEV] RFC: Support for multi-line arrow functions
From: george.banyard@gmail.com ("G. P. B.")

--000000000000e66d9b05b0fe0eb8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 th=
e
> 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 =E2=80=94 base=
d on the
> vote count in the sigle line RFC and the reaction on Nuno's PR, as well a=
s
> 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 =E2=80=94 even when=
 you
> personally disagree that it is. I've made the same argument before on thi=
s
> 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, =E2=80=A6 these are a=
ll
> 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:
>
> > =E2=80=9CCombined with PHP=E2=80=99s overall clunky syntax for doing fu=
nctional-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 se=
e in this book, a
> game-changer. While it doesn=E2=80=99t make anything new possible, it mak=
es 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.=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 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=3D1895
[2] https://github.com/php/php-src/pull/6221

--000000000000e66d9b05b0fe0eb8--