JEP 302: Lambda Leftovers
brian.goetz at oracle.com
Wed Dec 7 19:42:47 UTC 2016
> TLDR: I've seen direct evidence of not being able to shadow lambda
> parameters actually being beneficial for readability.
I believe you. Both ways have pros and cons; there are times when it
forces you to be clearer, and there are times when it just forces you to
crap up your code. The debate over this in the original JSR-335 EG
reflected this. Ultimately the decision didn't end up getting made on
the basis of one being demonstrably better than the other -- because no
one could offer a strong enough argument for either; instead, we hid
behind that last refuge of scoundrels, "consistency". Specifically, the
scoping rules seemed more consistent the way they were originally
written, but no one was really all that comfortable with the decision.
> The readability issue is really cropping up a lot with the lambdas code I'm
> seeing. Many developers are already following a short hand idiom for lambda
> variables e.g. using 'k' instead of 'key', along with some other idioms
> that do lessen the readability of lambdas based code in general.
Yes, this is very tempting. And for simple lambdas (x -> x + 1), its
just fine. But as lambdas get more complicated, developers don't always
adjust their habits, as you've observed.
The main place where the current scoping rules bite is when the argument
of the nested lambda _refers to the same thing_ as the same-named
argument in the outer lambda. Such as:
Function<K, V> mapGetter k -> map.computeIfAbsent(k, k -> new
Here, both k's are the same thing, so calling the second 'kk' seems
gratuitously specific. But this is just one use case; there are others
where multiple names would make the code more readable.
More information about the platform-jep-discuss