Defender Extension Methods -- Resolution and Invoccation

[Mikael Grev]

Maybe I have missed the discussion on this and if so I'm sorry.

Why can't we define the default method code directly in the extension? To me that would be the natural thing to do. Proxying it to some other method just looks like boiler code to me. I understand the "keep the interface code free" need but is it the only reason?


On Aug 4, 2010, at 23:58 PM, Brian Goetz wrote:

> There's currently no way to specify an extension method with no default.  But 
> you could easily simulate that with a default that throws UOE.
> 
> Resolution is fully dynamic.  Let's say you have the following:
> 
> interface I {
>     public extension void foo() default Moo.foo();
> }
> 
> class C implements I { }
> 
> class Client {
>     public void yada() {
>         C c = new C();
>         c.foo();
>     }
> }
> 
> At compile time, no non-default implementation exists.  But if C were 
> recompiled to provide an implementation (or I is recompiled to provide a 
> different default), at runtime that would be reflected in the behavior.
> 
> On 8/4/2010 5:49 PM, Mike Duigou wrote:
>>> From Maurizio's Sytax samples Doc:
>> 
>>> 3. Defender Methods
>>> -------------------
>>> 
>>> Defender methods are declared using the 'extension' keyword, as follows:
>>> 
>>> extension List<T>  map(Mapper<T>  r) default Collections.<T>listMapper;
>>> 
>>> A defender method declaration is structured in two parts, (i) a method signature, declaring formal arguments, formal type-arguments and return-type and (ii) a default implementation, that is, the implementation the method should default to if none is found in the class implementing the extended interface.
>> 
>> Have you considered extensions with no default? I understand that the defender is primarily intended to support interface evolution but providing a default implementation isn't always practical. I'd prefer to see a "missing implementation of xyz" compile error to a usage pattern which involves default methods who's only purpose is to generate a runtime exception for the unsupported operation.
>> 
>> Is the resolution of the extension method intended to occur at compile time or at invocation time? ie. will compiled code which refers to the extension method include a call to the named method through the interface or a call to the static default method. For greatest flexibility in interface evolution it would be much more useful if the resolution happens at the time the method is invoked.
>> 
>> Mike
>>