Bitten by the lambda parameter name

[Zhong Yu]

On Wed, Jul 17, 2013 at 4:47 AM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> On 15 July 2013 15:52, Remi Forax <forax at univ-mlv.fr> 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 !
>
> Just to note that it is correct that this not compiling. It should be
> viewed from the perspective of a code reader, not a code writer.

I think for code readers,

    computeIfAbsent(kind, kind -> new HashSet<>())

is better than

    computeIfAbsent(kind, _kind -> new HashSet<>())

    computeIfAbsent(kind, kind2 -> new HashSet<>())

    computeIfAbsent(kind, key -> new HashSet<>())

    computeIfAbsent(kind, k -> new HashSet<>())

    computeIfAbsent(kind, _ -> new HashSet<>())

    computeIfAbsent(kind, () -> new HashSet<>())


>
> There is no visible additional scope here, just an expression like any
> other. As a reader (without any further knowledge, including knowledge
> about lambdas) I'd expect that expression to have no additional scope,
> just like the ternary operator has no additional scope.
>
> Note that a different syntax would have affected this:
>
>   partySetMap.computeIfAbsent(kind, #(kind) {new HashSet<>()}).add(party);

# would be nice....

>
> In this case, there is something that looks a lot more like an inner
> class and a method, in which case I'd expect the method parameter to
> have a different scope.
>
> The borderline case is
>   partySetMap.computeIfAbsent(kind, (kind) -> new HashSet<>()).add(party);
>
> where there is something that looks vaguely like a method parameter.
> But I don't think its enough to convince me that the parameter should
> be in a different scope.
>
> Stephen
>