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
