JEP 302: Lambda Leftovers

[Maurizio Cimadamore]

Well taken points Martin. As you mention, we are aware of the 
readability issue, and I think this is an area where it could be 
beneficial to gather some data after an initial round of implementation 
to see where things stand. As a kind of a counter example, consider this:

Map<String, String> mss = ...

String s = "hello";
mss.computeIfAbsent(s, s2 -> s2.toLowerCase());

vs. this:

mss.computeIfAbsent(s, _ -> s.toLowerCase());

The first is a non-capturing lambda - the second is a capturing one! So, 
while I agree that expressiveness-wise, the two solutions are similar 
(and also I agree that readability-wise the second is probably 
superior), the performance model is not the same - and if you care about 
your lambdas being non-capturing, using ugly names is (currently) the 
only way out, I believe. If shadowing rules are tweaked, you will be 
able to say:

mss.computeIfAbsent(s, s -> s.toLowerCase());

Which is better than the first option (one less throwaway name), and 
that also gives you the performance model you'll likely want in this 
case. But I agree that it raises the question of whether the two 's' are 
really the same or not.

Regarding your point that bad names are the fault of the developer - I 
agree only partially: I don't think there are many sensible name choices 
for the 's2' variable above.

Maurizio


On 07/12/16 09:10, Martijn Verburg wrote:
> I'll preface this with IANALE (I Am Not A Language Expert),
>
> TLDR: I've seen direct evidence of not being able to shadow lambda
> parameters actually being beneficial for readability.
>
> -----
>
> I currently read a lot of code by developers who are using lambdas and
> wanted to add some anecdotal evidence to the shadowing use case.  I notice
> the JEP author has already stated:
>
> "It would be desirable to lift this restriction, and allow lambda
> parameters (and locals declared with a lambda) to shadow variables defined
> in enclosing scopes. (One possible argument against is readability: if
> lambda parameters are allowed to shadow, then in the above example, the
> identifier 'key' means two different things in the two places where it is
> used, and there seem to be no syntactic barrier to separate the two
> usages.)"
>
> ---
>
> 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. This is
> clearly not the fault of the language / syntax today, it's more the fault
> of the developer! A similar argument can be applied to the proposed 'var'
> JEP, as long a developers name their variables properly, readability is
> maintained.
>
> That said, the current status quo of not being able to shadow lambda
> parameters is actually forcing developers to think more clearly about
> naming and scope, which is generally a good thing.  My concern is that if
> we are able to shadow lambda parameters this will cause even more confusion
> to the reader unless they carefully hover over the section in their
> favourite IDE *or* have the 'scope of variables outside of the lambda vs
> inside the lambda' concept firmly in their heads (an educational issue).
>
> ----
>
> As a side note, JEPs 300, 301 and 302 are very cool. Anything that improves
> type inference and safety automatically for the developer is a welcome
> addition and I appreciate how hard it is to get that right internally in
> the JVM and in the language.
>
>
>
> Cheers,
> Martijn
>
> On 7 December 2016 at 08:37, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> I really appreciate this proposal,
>> i hit both better disambiguation and shadow of lambda parameters issues
>> quite frequently.
>>
>> For treatment of underscores,
>> as i understand, the idea is that you can use '_' as parameter without
>> having '_' being entered in the scope of the method,
>> i.e. this code will not compile:
>>
>>    void setBar(Bar _) {
>>      foo(_);
>>    }
>>
>> cheers,
>> Rémi
>>
>> ----- Mail original -----
>>> De: "mark reinhold" <mark.reinhold at oracle.com>
>>> À: "maurizio cimadamore" <maurizio.cimadamore at oracle.com>
>>> Cc: platform-jep-discuss at openjdk.java.net
>>> Envoyé: Mercredi 7 Décembre 2016 00:50:02
>>> Objet: JEP 302: Lambda Leftovers
>>> New JEP Candidate: http://openjdk.java.net/jeps/302
>>>
>>> - Mark