Fun with method references

[Rémi Forax]

Le 06/08/2010 23:48, Rémi Forax a écrit :
> Le 06/08/2010 22:44, Brian Goetz a écrit :
>    
>> They are type checked at runtime, making them dynamically type-safe.  However,
>> both generics and MHs have the problem that you could not overload methods
>> whose arguments are function types; since under either scheme
>>
>>      foo({ String =>   int } stringHandler) { ... }
>>      foo({ Bar =>   int } barHandler { ... }
>>
>> could not be overloaded since they would have the same erasure.  But users
>> would find it a very confusing restriction (especially if the scheme did
>> permit overloading on arity, as some function-to-generics mappings permit.)
>>
>> This restriction really makes surfacing function types a non-starter at this
>> point.
>>
>>      
>    

or worst

interface Handler<A> {
   public int handle(A a);
}

void foo(Handler<String> stringHandler) { ... }
void foo(Handler<Bar> barHandler) { ... }

which exhibits exactly the same erasure problem.

Rémi

> Not a good example, in my opinion.
> using SAM interfaces instead:
>
> interface Foo1 {...}
> interface Foo2 {...}
>
> void foo(Foo1 foo) { ... }
> void foo(Foo2 foo) { ... }
>
> Having two overload methods with interfaces is a notorious poor design.
> You will always find someone that create a class that implement both
> interfaces.
>
> I have seen more than once a code containing a class implementing
> Callable *and* Runnable
> and trying to submit an object implementing that class to an executor
> service.
> The funny thing with this example is that the developer have to choose
> if he want to receive
> a Future<?>  or a Future<Void>.
>
> Rémi
>
>