Hey everyone
I’m on team C as well.
One complaint about the RFC is that it doesn’t support multi-statement bodies.
Arrow functions are especially useful for functional programming where it’s
common to return a value in a single expression. Using multiple statements
(partly) destroys the usefulness of the arrow function as that would require a
`return` keyword, braces and semicolons.
Additionally, long closures with multiple statements may actually benefit from
not implicitly capturing variables from the outer scope, especially since in
PHP there’s no keyword to declare your variables, which might lead to you
accidentally capturing a variable instead of creating a new one. This isn’t as
much of a problem with arrow functions as assignments are much less useful when
you’re limited to a single expression.
Thus it might be best to use each when most appropriate.
@Levi, @Bob
Just out of curiosity, are variables captured by value for a specific reason?
Would there be any limitations capturing the variables by reference?
And also, have you considered letting people vote for their preferred arrow
function syntax?
I kinda don’t think we’re gonna find an agreement as there are so many
different opinions.
Regards,
Ilija
On 5 Feb 2017, 18:52 +0100, Rowan Collins <rowan.coll...@gmail.com>, wrote:
> On 30/01/2017 17:55, Levi Morrison wrote:
> > Here is an example of an existing closure:
> >
> > function ($x) use ($arr) {
> > return $arr[$x];
> > }
> >
> > This RFC proposes syntax and semantics to simplify this common usage to:
> >
> > fn($x) => $arr[$x]
>
> 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 [$foo,
> $bar] is a shorter syntax for array($foo, $bar))
> (b) improved *semantics* for declaring closures, where you don't have to
> 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 mind
> makes a big difference to what you see as "better" or "worse".
>
> Many of those starting from view (a) or (b) would like to see the syntax
> extended to closures with full bodies, and perhaps eventually become the
> most common way of declaring closures. Even if not included initially,
> they want to design the feature with that in mind. From view (c), the
> syntax is expected to exist alongside existing closures forever, just as
> we have both "for" and "while" loops.
>
> For 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?
>
> This is a good summary of the natural position from view (a) or (b) - if
> this is going to be the new way of declaring closures, we should make it
> the best way of declaring closures.
>
> If it was just about making the syntax shorter, this would be fine -
> like [...] for array(...) - but the Big Idea here is automatic capture
> 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, not
> 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 strange
> > 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 "strange" or
> "messy" 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 "6 more characters" for*not* using the
> > function keyword?
>
> This question presumably comes from view (b) - if it's just another way
> of declaring a function, why do we need a new keyword?
>
> From view (a), those 6 more characters are enough argument in
> themselves, because if the aim is to make it shorter, why stop early?
> From 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 "fn" is *too much* like "function"; perhaps we
> should find something *more* distinct, like "lambda" ($foo = lambda($x)
> => $x * 2). That would have the advantage of giving a proper name to
> these new callables, and make them easier to discuss: "when your
> callback is too complex for a lambda, use a closure".
>
> 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 "obviously better" for you may
> be "obviously worse" for someone else, simply because you are measuring
> against different aims.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
