On Tue, Jan 31, 2017 at 12:29 PM, Larry Garfield <la...@garfieldtech.com> wrote:
> On 01/31/2017 05:14 AM, Bob Weinand wrote: > >> >>> In the case that regular closures got auto-capture, would a >>>> `use($foo, $bar, $baz)` segment on a closure still be honoured (i.e. >>>> disable auto-capture), and would it have any impact (positive or >>>> negative) on performance/memory usage? After several years of JS >>>> closure ‘fun’ I kind of like that with PHP you only inherit the >>>> variables you explicitly `use()` in closures. >>>> >>> Wouldn't there be just too many existing closures, which do not use >>> `use` but (maybe) expect a clean scope? >>> >> >> The RFC is exclusively proposing single-expression short Closures. >> We do NOT want multi-statement short Closures; it is a *feature* that >> generic Closures need an "use ($foo, $bar)". >> This vastly improves readability and debuggability - it basically tells >> you whether the variables inside the code are imported or not. As Stephen >> Reay notes: >> >>> After several years of JS >>>> closure ‘fun’ I kind of like that with PHP you only inherit the >>>> variables you explicitly `use()` in closures. >>>> >>> >> So, auto-import for generic Closures definitely isn't an option. >> Just on short, single-line Closures there is no benefit to "use ()", as >> EVERY variable used in the short Closure is supposed to be an imported >> variable. There is no point in forcing the user to distinguish between >> imported and local variable here. >> >> Also, using "fn" in favor of "function" has the advantage of less clutter >> in one line. Compare >> >> array_map(fn($x) => $x + 1) >> >> to >> >> array_map(function($x) => $x + 1) >> >> The syntactical construction is already pretty clearly showing what's >> going on. The "function" keyword itself is already larger than the whole >> body. It distracts while reading the actual code. >> Additionally, using "fn" is optically highlighting the fact that it's a >> short-Closure with auto-import and not a normal Closure with explicit >> import. >> >> Thanks, >> Bob >> > > I must agree with Bob and the other authors. The entire point of this RFC > is to reduce the amount of typing, and therefore reading, that goes into > using simple closures as first-class values. Using longer keywords instead > of shorter ones is counter to that aim. It sounds like the earlier > proposal of keyword-less closures isn't technically feasible or it would > make sense to argue for that. > > My question is why there's no mention of HHVM short closures, or the > previous RFC to take that approach. See: > > https://docs.hhvm.com/hack/lambdas/introduction > > > For what it's worth I'd rather look at array_map( $x ==> $x + 1); than array_map( fn($x) => $x + 1 ) Not to mention the former isn't a bc break.
