JEP 302: Lambda Leftovers

[Martijn Verburg]

Hi Maurizio,

Hmm, interesting. Responses inline:

On 7 December 2016 at 10:47, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

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


Agreed, I know we shouldn't focus on syntax, but it does look nicer doesn't
it :-).


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

I agree finding a good name for s2 is harder, but if the code focuses on
whatever that string represents then something like this can work well for
naming?

String message = "hello";
messages.computeIfAbsent(message, transformedMessage ->
transformedMessage.toLowerCase());

Cheers,
Martijn


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