Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98084
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <37679ae0-eb90-2367-7fc0-8f0adf97a965@garfieldtech.com>
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
 <E6.ED.51557.B64EF885@pb1.pair.com> <3F428CA4-8211-44E6-9B60-62ADB47934B3@koalephant.com>
 <642a72cd-e322-0b22-452f-dfbd521aee02@php.net> <BLU436-SMTP4506E841E18C53E37A3CF4E24A0@phx.gbl>
 <37679ae0-eb90-2367-7fc0-8f0adf97a965@garfieldtech.com>
Date: Tue, 31 Jan 2017 13:16:27 -0500
Message-ID: <CAEUnE0cO04dQ6boek3GrykxXONH3cVuyUGSXUB2z5W0TK34_Lw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c047d4a43e77f054767ee67
Subject: Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
From: tendoaki@gmail.com (Michael Morris)

--94eb2c047d4a43e77f054767ee67
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 31, 2017 at 12:29 PM, Larry Garfield <larry@garfieldtech.com>
wrote:

> On 01/31/2017 05:14 AM, Bob Weinand wrote:
>
>>
>>> In the case that regular closures got auto-capture, would a
>>>> `use($foo, $bar, $baz)` segment on a closure still be honoured (i.e.
>>>> disable auto-capture), and would it have any impact (positive or
>>>> negative) on performance/memory usage? After several years of JS
>>>> closure =E2=80=98fun=E2=80=99 I kind of like that with PHP you only in=
herit the
>>>> variables you explicitly `use()` in closures.
>>>>
>>> Wouldn't there be just too many existing closures, which do not use
>>> `use` but (maybe) expect a clean scope?
>>>
>>
>> The RFC is exclusively proposing single-expression short Closures.
>> We do NOT want multi-statement short Closures; it is a *feature* that
>> generic Closures need an "use ($foo, $bar)".
>> This vastly improves readability and debuggability - it basically tells
>> you whether the variables inside the code are imported or not. As Stephe=
n
>> Reay notes:
>>
>>> After several years of JS
>>>> closure =E2=80=98fun=E2=80=99 I kind of like that with PHP you only in=
herit the
>>>> variables you explicitly `use()` in closures.
>>>>
>>>
>> So, auto-import for generic Closures definitely isn't an option.
>> Just on short, single-line Closures there is no benefit to "use ()", as
>> EVERY variable used in the short Closure is supposed to be an imported
>> variable. There is no point in forcing the user to distinguish between
>> imported and local variable here.
>>
>> Also, using "fn" in favor of "function" has the advantage of less clutte=
r
>> in one line. Compare
>>
>> array_map(fn($x) =3D> $x + 1)
>>
>> to
>>
>> array_map(function($x) =3D> $x + 1)
>>
>> The syntactical construction is already pretty clearly showing what's
>> going on. The "function" keyword itself is already larger than the whole
>> body. It distracts while reading the actual code.
>> Additionally, using "fn" is optically highlighting the fact that it's a
>> short-Closure with auto-import and not a normal Closure with explicit
>> import.
>>
>> Thanks,
>> Bob
>>
>
> I must agree with Bob and the other authors.  The entire point of this RF=
C
> is to reduce the amount of typing, and therefore reading, that goes into
> using simple closures as first-class values.  Using longer keywords inste=
ad
> of shorter ones is counter to that aim.  It sounds like the earlier
> proposal of keyword-less closures isn't technically feasible or it would
> make sense to argue for that.
>
> My question is why there's no mention of HHVM short closures, or the
> previous RFC to take that approach.  See:
>
> https://docs.hhvm.com/hack/lambdas/introduction
>
>
>

For what it's worth I'd rather look at

array_map( $x =3D=3D> $x + 1);

than

array_map( fn($x) =3D> $x + 1 )

Not to mention the former isn't a bc break.

--94eb2c047d4a43e77f054767ee67--