Bitten by the lambda parameter name

Zhong Yu zhong.j.yu at
Tue Jul 16 09:49:06 PDT 2013

Hi Maurizio, I don't think Remi's example is an isolated case. I
personally encountered a similar case too

    interface Foo

        void onBar(Consumer<Foo>)

the consumer will be fed with exactly `this` object.

Ideally the method could have been designed as

        void onBar(Runnable action)

however, in majority of cases, `action` will need to access `this`, so
the Consumer version is more efficient than the Runnable version on
call site.

I imagine that this will become a very common concern for many APIs.

With the Consumer version, we cannot do

    foo.onBar( foo -> { ... } );  // `foo` name clash !

we can use method reference though, ::handleBar );

    static void handleBar(Foo foo){...}

which could be perfect for some cases, but not ideal for others.

Zhong Yu

On Tue, Jul 16, 2013 at 10:30 AM, Maurizio Cimadamore
<maurizio.cimadamore at> wrote:
> On 16/07/13 16:20, Remi Forax wrote:
>> computeIfAbsent, put the computed value in the Map if the couple
>> key/value doesn't exist,
>> thus computeIfAbsent is useful when using a Map as a cache.
>> The method that provide a default value is getOrDefault and yes, it's
>> often better to send the default value when creating the Map,
>> because the default value usually doesn't change but at the same time,
>> storing a default value like Collections.emptySet() in each map is not
>> very memory efficient.
> Well, the lambda is there exactly for that reason - I believe, so that
> default values are created lazily. What I was saying is - any reason as
> to why the lambda shouldn't be passed to the Map constructor, rather
> than to the get method?
> Maurizio

More information about the lambda-dev mailing list