Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112010
X-MailCleaner-return_path: brendt@stitcher.io
X-MailCleaner-sender_address: brendt@stitcher.io
X-MailCleaner-recipients: internals@lists.php.net
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3064C139-8F44-425A-89D7-45A59CBCFB71"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Tue, 6 Oct 2020 10:53:04 +0200
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>
To: Levi Morrison via internals <internals@lists.php.net>
In-Reply-To: <873361ff-02c8-b9df-9b7a-c9e89e25a880@gmx.net>
Message-ID: <7F014A40-2D47-4DA6-8A38-59518218F9CA@stitcher.io>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-MailCleaner-TrustedIPs: Ok
Subject: Re: [PHP-DEV] RFC: Support for multi-line arrow functions
From: brendt@stitcher.io (Brent Roose)

--Apple-Mail=_3064C139-8F44-425A-89D7-45A59CBCFB71
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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]
>=20

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 well as my experience from an OSS maintainer point of view.

Furthermore, the `use(*)` syntax misses the point of this proposal: it's =
not about being able to use all variables from the outer scope, 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 =
this list: it's clear that the PHP community _wants_ these changes: =
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.=20

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 =
functional-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.
>=20
> That is, until PHP 7.4.
>=20
> PHP 7.4=E2=80=99s introduction of short lambdas is, as we=E2=80=99ll =
see 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 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.=20

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.=20

Kind regards
Brent

[1] https://wiki.php.net/rfc/arrow_functions_v2 =
<https://wiki.php.net/rfc/arrow_functions_v2>=20
[2] https://leanpub.com/thinking-functionally-in-php =
<https://leanpub.com/thinking-functionally-in-php>=20




> On 5 Oct 2020, at 12:39, Andreas Leathley <a.leathley@gmx.net> wrote:
>=20
> On 05.10.20 12:15, Deleu wrote:
>> To me that seems like a great argument in favour of the proposal. If =
you'll
>> want all variables to be imported (which in this case makes =
completely
>> sense), then `fn() {}` or `fn() =3D> {}` is much less verbose and =
inline with
>> the mentality to reach for short closures. We reach for short =
closures to
>> avoid `use()` and convey that the outer process is intertwined with =
the
>> inner process. `fn()` allows to strengthen the concept that there's =
no real
>> separation between running SQL stuff in a `callable` that wraps a =
database
>> transaction.
>=20
> Not necessarily: the arrow functions were specifically implemented for
> very short anonymous functions with a return value. Making them more =
and
> more like the existing "function" syntax would lead to having two
> different ways of defining anonymous functions that mainly =
differentiate
> themselves by including the parent scope by default or not.
>=20
> I like the "function () use (*)" suggestion because it is explicit and
> opt-in. A shorter syntax like "fn () {}" is less clear, and it could
> lead to many people always using fn just because it is faster to write
> (and less to think about), which then could lead to unintended side
> effects because variables are being copied from the parent scope each
> time. When you see a usage of "fn () {}" while reading code you would
> not know if the person used it because it was faster to write, or if =
the
> parent scope variables are really needed.
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20


--Apple-Mail=_3064C139-8F44-425A-89D7-45A59CBCFB71--