Bitten by the lambda parameter name

[Maurizio Cimadamore]

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.

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