Re: Re: [RFC][Discuss] Arrow Functions

From: Date: Tue, 31 Jan 2017 21:27:40 +0000
Subject: Re: Re: [RFC][Discuss] Arrow Functions
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-98095@lists.php.net to get a copy of this message
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]

« previous php.internals (#98095) next »