Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98087
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEUnE0cO04dQ6boek3GrykxXONH3cVuyUGSXUB2z5W0TK34_Lw@mail.gmail.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> <CAEUnE0cO04dQ6boek3GrykxXONH3cVuyUGSXUB2z5W0TK34_Lw@mail.gmail.com>
Date: Tue, 31 Jan 2017 16:36:55 -0200
Message-ID: <CAEsg9X1BXaVXM0GvYOO_d9aHoo5PtR80kLhprOmeMV=dt2+URw@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f403045f8efcac9e2e05476838d3
Subject: Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
From: david.proweb@gmail.com (David Rodrigues)

--f403045f8efcac9e2e05476838d3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I guess that should avoid the usage of fn() or function() before arguments
(or then make it optional, but I don't like to give much options).

Some possibilites:

array_map(($x) return $x + 1); // or
array_map(($x) =3D $x + 1); // or
array_map(($x) =3D> $x + 1); // or
array_map(($x) { $x + 1 });

Then:

array_map(($x) use ($y) { $x + $y });
array_map(($x) { $x + $y });
=E2=80=8B// maybe use($y) is needless here
array_map(($x) { $x + $this->y });

Or if arguments could be omitted:

array_map({ $0 + 1 });


2017-01-31 16:16 GMT-02:00 Michael Morris <tendoaki@gmail.com>:

> 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 =
inherit 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 tell=
s
> >> you whether the variables inside the code are imported or not. As
> Stephen
> >> Reay notes:
> >>
> >>> After several years of JS
> >>>> closure =E2=80=98fun=E2=80=99 I kind of like that with PHP you only =
inherit 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 ()", a=
s
> >> 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
> clutter
> >> 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 who=
le
> >> 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
> RFC
> > is to reduce the amount of typing, and therefore reading, that goes int=
o
> > using simple closures as first-class values.  Using longer keywords
> instead
> > of shorter ones is counter to that aim.  It sounds like the earlier
> > proposal of keyword-less closures isn't technically feasible or it woul=
d
> > 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.
>



--=20
David Rodrigues

--f403045f8efcac9e2e05476838d3--