Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98249
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain me.com designates 17.172.80.96 as permitted sender)
Date: Tue, 07 Feb 2017 19:58:15 +0100
To: internals@lists.php.net, Rowan Collins <rowan.collins@gmail.com>,
 Levi Morrison <levim@php.net>, Bob Weinand <bwoebi@php.net>
Message-ID: <8d4ee559-1ad2-4d65-ae4f-207e59f056e3@Spark>
In-reply-to: <97bb5051-6413-b78a-e981-ad8858caec4c@gmail.com>
References:
 <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
 <97bb5051-6413-b78a-e981-ad8858caec4c@gmail.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary=589a1a49_6b8b4567_bbdc
Subject: Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
From: ilija.tovilo@me.com

--589a1a49_6b8b4567_bbdc
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hey everyone

I=E2=80=99m on team C as well.

One complaint about the R=46C is that it doesn=E2=80=99t support multi-st=
atement bodies. Arrow functions are especially useful for functional prog=
ramming where it=E2=80=99s common to return a value in a single expressio=
n. Using multiple statements (partly) destroys the usefulness of the arro=
w function as that would require a =60return=60 keyword, braces and semic=
olons.

Additionally, long closures with multiple statements may actually benefit=
 from not implicitly capturing variables from the outer scope, especially=
 since in PHP there=E2=80=99s no keyword to declare your variables, which=
 might lead to you accidentally capturing a variable instead of creating =
a new one. This isn=E2=80=99t as much of a problem with arrow functions a=
s assignments are much less useful when you=E2=80=99re limited to a singl=
e expression.

Thus it might be best to use each when most appropriate.

=40Levi, =40Bob
Just out of curiosity, are variables captured by value for a specific rea=
son=3F
Would there be any limitations capturing the variables by reference=3F

And also, have you considered letting people vote for their preferred arr=
ow function syntax=3F
I kinda don=E2=80=99t think we=E2=80=99re gonna find an agreement as ther=
e are so many different opinions.

Regards,
Ilija


On 5 =46eb 2017, 18:52 +0100, Rowan Collins <rowan.collins=40gmail.com>, =
wrote:
> On 30/01/2017 17:55, Levi Morrison wrote:
> > Here is an example of an existing closure:
> >
> > function (=24x) use (=24arr) =7B
> > return =24arr=5B=24x=5D;
> > =7D
> >
> > This R=46C proposes syntax and semantics to simplify this common usag=
e to:
> >
> > fn(=24x) =3D> =24arr=5B=24x=5D
>
> I think a lot of the disagreements and confusions on this thread come
> down to there being three fundamental views of what this new syntax is =
for:
>
> (a) an improved syntax for declaring closures (in the way that =5B=24fo=
o,
> =24bar=5D is a shorter syntax for array(=24foo, =24bar))
> (b) improved *semantics* for declaring closures, where you don't have t=
o
> list the variables to be captured
> (c) a new kind of closure designed for specific use cases, with its own=

> syntax and semantics
>
> These aren't mutually exclusive aims, but which of them you have in min=
d
> makes a big difference to what you see as =22better=22 or =22worse=22.
>
> Many of those starting from view (a) or (b) would like to see the synta=
x
> extended to closures with full bodies, and perhaps eventually become th=
e
> most common way of declaring closures. Even if not included initially,
> they want to design the feature with that in mind. =46rom view (c), the=

> syntax is expected to exist alongside existing closures forever, just a=
s
> we have both =22for=22 and =22while=22 loops.
>
> =46or the record, I generally come from view (c).
>
>
> On 05/02/2017 11:10, Rasmus Schultz wrote:
>
> > as long as we're introducing a new form and syntax, why make it*less*=
 capable than
> > ordinary PHP closures=3F
>
> This is a good summary of the natural position from view (a) or (b) - i=
f
> this is going to be the new way of declaring closures, we should make i=
t
> the best way of declaring closures.
>
> If it was just about making the syntax shorter, this would be fine -
> like =5B...=5D for array(...) - but the Big Idea here is automatic capt=
ure
> of variables, and that is a lot more than just a nicety of syntax. As
> Rasmus L. has pointed out, making automatic variable capture the norm
> would be a huge change in how PHP defined variable scope.
>
> Since the comparison to JS keeps coming up, consider this: in JS, *all*=

> functions capture scope greedily when they're declared; in PHP, *no*
> functions capture scope automatically; the use() clause maintains that
> rule for anonymous functions, and (in my opinion) that is a feature, no=
t
> a mistake that needs fixing.
>
> > At the very least, I feel there should be feature
> > parity - otherwise, code in the wild is going to continue to be a str=
ange
> > mess of one form or the other, which doesn't help with language
> > comprehension at all
>
> To be clear, from view (c), there is absolutely nothing =22strange=22 o=
r
> =22messy=22 about future code having both closures and arrow-functions;=
 they
> are different tools, to be used in different circumstances.
>
>
> On 04/02/2017 07:40, Stephen Reay wrote:
> > So, is there any argument besides =226 more characters=22 for*not* us=
ing the function keyword=3F
>
> This question presumably comes from view (b) - if it's just another way=

> of declaring a function, why do we need a new keyword=3F
>
> =46rom view (a), those 6 more characters are enough argument in
> themselves, because if the aim is to make it shorter, why stop early=3F=

> =46rom view (c), the fact that the keywords are different is a feature
> not a bug - these aren't functions in the normal sense, they are a new
> way of defining a callable, so they *should* look different.
>
>
> On 04/02/2017 20:49, Larry Garfield wrote:
> > The way I see it, the point of a short-closure is to take a simple
> > expression and wrap it into a function so that it can be plugged into=

> > a function context. I don't even think of it in the same way I would
> > a named function/method, more casting an expression to a function.
>
> This, meanwhile, is a good summary of view (c), and expresses my view
> better than I could myself.
>
> If anything, I agree that =22fn=22 is *too much* like =22function=22; p=
erhaps we
> should find something *more* distinct, like =22lambda=22 (=24foo =3D la=
mbda(=24x)
> =3D> =24x * 2). That would have the advantage of giving a proper name t=
o
> these new callables, and make them easier to discuss: =22when your
> callback is too complex for a lambda, use a closure=22.
>
> Obviously that would imply permanently cutting off all chance of full
> function bodies with auto capture. Personally, I think that's a good
> thing, but I realise not everyone agrees.
>
>
> In short, remember that something that is =22obviously better=22 for yo=
u may
> be =22obviously worse=22 for someone else, simply because you are measu=
ring
> against different aims.
>
> Regards,
>
> --
> Rowan Collins
> =5BIMSoP=5D
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--589a1a49_6b8b4567_bbdc--