Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112148
To: internals@lists.php.net
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>
 <9A58B811-37C4-46C8-A7A9-B558752362F3@stitcher.io>
 <CAFPFaM+aeqrvaPpAUgZHV703PGcQ=puadeAKQkctxR=P6bKcwg@mail.gmail.com>
 <CAG9XoMRnYZ_b1pLsM2qFa-r19QJx19PE1mR_p_uoQMzz3R66mA@mail.gmail.com>
Message-ID: <9aa03cfc-a067-cc07-8dd9-50b95ae681ed@gmail.com>
Date: Fri, 30 Oct 2020 18:06:51 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <CAG9XoMRnYZ_b1pLsM2qFa-r19QJx19PE1mR_p_uoQMzz3R66mA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] RFC: Support for multi-line arrow functions
From: rowan.collins@gmail.com (Rowan Tommins)

On 29/10/2020 22:49, Benjamin Morel wrote:
> On Tue, 6 Oct 2020 at 14:09, G. P. B. <george.banyard@gmail.com> wrote:
>
> Actually there is a precedent in PHP where braces don't create a new 
> scope:
>      $a = 1;
>
>      {
>          $a++;
>      }
>
>      echo $a; // 2


This is true. Indeed, in general, scope in PHP is not to the nearest 
pair of braces - if statements and loops don't create a new scope - but 
it is, with very few exceptions, to the current function, with no 
automatic inheritance/capture from the outer scope.

The fact that arrow functions *don't* have braces makes them look less 
like a normal function, so it is less surprising that they capture from 
their surrounding scope. The fact that they are limited to a single 
expression also reinforces that they are intended for a specific use 
case, and are not intended as a replacement for all anonymous functions.



> Let's put it into context, here is how one of my service methods looks like:
>
>      return $connection->transactional(function() use ($authorId,
> $activityId, $parentId, $comment) {
>
> ... and this is not the largest one. Let's see how it would look like with
> this proposal:
>
>      return $connection->transactional(fn() => {


Just to be clear, the major gain here is not replacing the 10 characters 
"function()" with the 7 characters "fn() =>", it is eliminating the list 
of captured variables. So you would get equally clean code with a 
"capture all" syntax, such as:

     return $connection->transactional(function() use(*) {

or Sara's suggestion from earlier today:

     return $connection->transactional(function() use($) {


If I've counted right, this takes your example from 46 characters down 
to 17; but more importantly, that 17 is fixed no matter how many extra 
variables you want to capture or how long you make their names.


> And I'm not worried about scope leaking:
> usually, the closure takes up most of my service method.


To me, this illustrates exactly why we should have an explicit 
"auto-capture" syntax, rather than extending arrow functions: this is a 
form you would use in specific situations where you know it's 
appropriate, *not* a general-purpose replacement for the existing syntax.

As well as being shorter than the current syntax, arrow functions would 
remind people of JavaScript, where it's considered best practice to use 
arrow functions as much as possible, because they have *better* scoping 
- in particular, they automatically bind "this", which PHP closures 
already do.

There are certainly use cases where automatic capture leads to more 
elegant code than explicit capture; but there are also plenty of cases 
where it makes code hard to follow, and leads to subtle bugs. That's why 
I would like the two syntaxes to feel like equal options to choose between.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]