Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98095
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.68 as permitted sender)
To: internals@lists.php.net
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
 <E6.ED.51557.B64EF885@pb1.pair.com>
 <CADVQu1T5Q63vph6nGu5DEwiUP6vxKxHG18ZgiGPmgakGEya6Bg@mail.gmail.com>
 <1E.BA.51557.966F0985@pb1.pair.com>
Message-ID: <a74a98c8-79f9-4c43-df57-153f19627f8b@gmail.com>
Date: Tue, 31 Jan 2017 21:27:40 +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: <1E.BA.51557.966F0985@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions
From: rowan.collins@gmail.com (Rowan Collins)

On 31/01/2017 20:41, Andrea Faulds wrote:
> That's the idea. I'd prefer it if auto-capture was not restricted to 
> single-expression functions (“arrow functions”). Though arrow 
> functions make most sense with auto-capture, it doesn't need to be 
> stricted to them. 

I respectfully disagree completely.

Variable scope in PHP is very simple: inside a function, all variables 
are local to that function, and fetching them from anywhere else 
requires them to be enumerated with a specific keyword (e.g. global, 
static, use). The only exceptions are superglobals, the magic $this, and 
the odd mysterious materialisation like $http_response_header [1]. This 
means you can look at a function in isolation, no matter how it's 
declared, and see where every variable comes from.

[1]: http://php.net/manual/en/reserved.variables.httpresponseheader.php

Auto-capture with a full function body would be throwing out that 
principle. If a variable was read from before it was assigned to, that 
*might* mean it was unset, or it *might* mean it was imported from an 
outer scope. Changing the variable name in the outer scope might or 
might not require you to look for that variable name in the closure; 
adding a variable in the outer scope might *accidentally* change the 
behaviour of the closure; and so on.

This is a lot easier in Javascript, although still a cause of confusion, 
because you can carry on until you hit "var" or "let". I understand C# 
also has auto-importing closures, but it too requires variables to be 
declared at some point.


Initially, I was sceptical of auto-capture even with a single 
expression, but I've come round to its usefulness in short closures. 
Limiting it to a single expression ensures it's short, and means you can 
assume that *all* variables in the expression are imported other than 
those listed as parameters.

Just an opinion, obviously, but I'm glad that the current proposal is 
limited to and optimised for this single expression case.

Regards,

-- 
Rowan Collins
[IMSoP]