2017-01-31 12:14 GMT+01:00 Bob Weinand <bobw...@hotmail.com>:
> Hey,
>
> > Am 31.01.2017 um 11:23 schrieb Michael Wallner <m...@php.net>:
> >
> > On 31/01/17 05:53, Stephen Reay wrote:
> >> Hi Andrea, All,
> >>
> >>> On 31 Jan 2017, at 08:12, Andrea Faulds <a...@ajf.me> wrote:
> >>>
> >>> Is it necessary to introduce a new keyword, fn?
> >>>
> >>> I think you'd get a similar benefit from:
> >>>
> >>> function($x) => $arr[$x]
> >>>
> >>> Likewise, is it necessary to restrict auto-capture to the =>
> >>> syntax? Couldn't we allow the following?
> >>>
> >>> function ($x) {
> >>> return $arr[$x];
> >>> }
> >>>
> >>
> >> I agree that the `fn` keyword isn’t really necessary. I’ve never
> >> quite understood how arrow functions with implied returns etc are
> >> supposed to make for *more* readable code, but if they’re going to be
> >> part of the language please at least keep some consistency with
> >> regular closures.
> >
> > Yes, I also think that keeping the function keyword would be better.
> >
> >>
> >> 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)
>
"function" is actually easier to recognize than "fn" for me. Humans read
things by the first and last letter + contained letters, they don't read
each letter separately, so a little bit longer keyword doesn't hurt
readability, it might be even improved, because "function" is a keyword
people are used to. And it comes with the benefit of no BC break, because
"function" is already a keyword.
Also updating
array_map(function ($x) => 2 * $x, [...]);
to
array_map(function ($x) use (...) { ... }, [...]);
is a little bit easier then, just in case you need an additional statement
there.
> The syntactical construction is already pretty clearly showing what's
> going on. The "function" keyword itself is already larger than the whole
> body.
Now we're counting chars again instead of keeping the focus on actual
readability?
> It distracts while reading the actual code.
>
I disagree here, as mentioned above.
> 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 think I prefer "function" instead of "fn", but I can also live with "fn".
Regards, Niklas
