JEP 302: Lambda Leftovers
martijnverburg at gmail.com
Wed Dec 7 20:30:23 UTC 2016
On 7 December 2016 at 19:42, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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.
Apologies for having missed referencing that original discussion, I really
need to be more disciplined about searching the archives first!
> 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
>> 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
Ouch, yeah seeing code like that makes me as 'Joe/Jane Java' throw my hands
up and hope someone smarter than me understands what's going on. It's why
I'm particularly happy with these 3 JEPs overall, it's going to reduce
source code confusion.
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