lambda syntax tutorial

[Maurizio Cimadamore]

>> The actual argument type list associated with a method reference is optional:
>>
>> Foo#baz
>>
>>      
> I think you can't do that because inserting an overloading method
> is a source backward compatible change.
>
> With this syntax, inserting an overloading method may break method
> references.
>
>    
>> However, if required, actual argument types can be specified after the method references, enclosed in parenthesis, as in:
>>
>> Foo#baz(Integer, String).
>>
>> Note: the explicit syntax can be handy in case of overload resolution.
>>
>>      
> In my opinion, explicit syntax should be the only existing one.
>    
Uhmm, yes and no.
On the one hand, as Friedrik has pointed out, adding overloaded versions 
of a method to a class can already result in ambiguity errors (best 
case) or 'stale' resolution (worst case) anywhere else in the codebase.

On the other hand, I admit that this syntax is more prone to this kind 
of problems since the argument list is completely unspecified - but it's 
just matter of quantity, not quality ;-)

Explicit syntax does not entirely solve the problem, as explicit 
argument types might still undergo an overload resolution process:

interface A {}
interface B {}

class C implements A,B {}


class Foo {
void m(A a) {  }
}

Foo#m(C) //ok, this resolves to Foo.m(A)

now suppose to add a method to Foo:

class Foo {
void m(A a) {  }
void m(B a) {  }
}

Foo#m(C) //ambiguity here, both m(A) and m(B) apply!!


So, even with explicit syntax you have a breakage...

...unless you are proposing that Foo#m(C) should not compile in the 
first place (i.e. because there should be an exact match between the 
explicit types of the method reference and the underlying VM method 
descriptor).

Maurizio
> Rémi
>
>
>
>