Bitten by the lambda parameter name

[Peter Levart]

On 07/15/2013 07:11 PM, Remi Forax wrote:
> On 07/15/2013 07:05 PM, Maurizio Cimadamore wrote:
>> On 15/07/13 17:27, Remi Forax wrote:
>>> On 07/15/2013 05:59 PM, Maurizio Cimadamore wrote:
>>>> On 15/07/13 16:37, Remi Forax wrote:
>>>>> On 07/15/2013 05:34 PM, Maurizio Cimadamore wrote:
>>>>>> On 15/07/13 16:32, Maurizio Cimadamore wrote:
>>>>>>> On 15/07/13 16:28, Remi Forax wrote:
>>>>>>>> On 07/15/2013 05:13 PM, Maurizio Cimadamore wrote:
>>>>>>>>> On 15/07/13 15:52, Remi Forax wrote:
>>>>>>>>>> This snippet not compile,
>>>>>>>>>>      Kind kind = ...
>>>>>>>>>>      partySetMap.computeIfAbsent(kind, kind -> new
>>>>>>>>>> HashSet<>()).add(party);
>>>>>>>>>>
>>>>>>>>>> Each time I write more than a hundred lines of codes that use
>>>>>>>>>> some lambdas,
>>>>>>>>>> I fall into this trap.
>>>>>>>>>>
>>>>>>>>>> It's very annoying !
>>>>>>>>>>
>>>>>>>>>> Rémi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Annoying yes - but there is a reason for it? If we provide
>>>>>>>>> special scoping for lambda parameters then we will never be
>>>>>>>>> able to add control abstraction syntax in a nice way; not
>>>>>>>>> saying that it's something we want - but it's good to have
>>>>>>>>> option open at least.
>>>>>>>> It's a crystal ball argument, in the future if we do that then ...
>>>>>>>> It usually doesn't work because between now and the future, the
>>>>>>>> way the feature will be introduced will change.
>>>>>>>>
>>>>>>> Well, yes and no - I remember we discussed a lot whether a lambda
>>>>>>> should look (semantically) more like a block or an inner class.
>>>>>>> We decided it should look like the former. This is a consequence
>>>>>>> of that decision. I think that mixing and matching semantics on a
>>>>>>> by-need basis is not a good idea.
>>>>>> And - one might argue the code you are trying to write is not that
>>>>>> readable in the first place (adding random suffixes just to get it
>>>>>> through javac is not very elegant readability-wise, but it does
>>>>>> convery the concept that the two references of 'kind' which occur
>>>>>> very close one to the other are indeed unrelated).
>>>>>>
>>>>>> Maurizio
>>>>> Most of the time, there are not unrelated because the two variables
>>>>> carry the same reference like in Map.computeIfAbsent.
>>>>> Correctly naming things (variables, methods, types, etc) is one of
>>>>> the hardest things you do when you write code,
>>>>> in that context, having to find two different names for the same
>>>>> things is really weird.
>>>> But - back to your code, couldn't the lambda be shared among all
>>>> uses of computeIfAbsent that target your partySetMap?
>>> I use computeIfAbsent because I want my Map to act as a cache, so
>>> there is only one call to computeIfAbsent.
>> I still kinda think yours is more a problem of having to forcefully
>> put a name where something like '_' (i.e. in Scala) would have been
>> fine, rather than the fact that you are forced to pick a different name.
> I often use 'unused' instead of the wunderbar in Java.
> Anyway, sometime the key is useful and calling map.computeIfAbsent(key,
> key -> ...) is better than
> map.computeIfAbsent(key, thisIsTheSameKeyButWithADifferentName -> ...).
>
> Rémi

Perhaps here, an overloaded Map.computeIfAbsent that takes a Supplier 
instead of Function would be handy. Even when you need the key to 
construct new value, it is usually ready in some effectively-final 
variable in the scope. And when you don't need the key, a constructor 
reference could be applied like:

partySetMap.computeIfAbsent(kind, HashSet::new).add(...);


Regards, Peter

>
>> Maurizio
>>>> Maurizio
>>> Rémi
>>>
>>>>> Rémi
>>>>>
>>>>>>> Maurizio
>>>>>>>> In this peculiar case, if we add control abstraction syntax we
>>>>>>>> will use a different syntax,
>>>>>>>> so it's very annoying for no reason.
>>>>>>>>
>>>>>>>>> Maurizio
>>>>>>>> Rémi
>>>>>>>>
>