Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98209
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.65 as permitted sender)
To: internals@lists.php.net
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
Message-ID: <97bb5051-6413-b78a-e981-ad8858caec4c@gmail.com>
Date: Sun, 5 Feb 2017 17:51:49 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
From: rowan.collins@gmail.com (Rowan Collins)

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]