JEP 302: Lambda Leftovers

[Martijn Verburg]

Hi Brian,

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
>> 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
> PlaceHolder());
>

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.
>

Cheers,
Martijn