Defender Extension Methods -- Resolution and Invoccation

[Brian Goetz]

Your characterization of "keep interfaces code-free" is pretty close.  While 
the introduction of default methods unfortunately dirties the distinction 
between interfaces and classes, we have taken a much smaller step than we 
could have (say, to mixins or traits or full multiple inheritance) in order to 
keep as much as possible to the true spirit of interfaces, which we still 
believe in.  Therefore we believe that choosing a syntactic option that 
reflects that this philosophical leaning is in the best interest of the 
community.

As designed, this is an interface evolution mechanism, not a primary 
implementation mechanism.  Pushing some minor inconvenience to library 
maintainers for the sake of less confusion on the part of the broad user base 
is a tradeoff we're happy to make every day of the week.

Of course, some people will notice this mechanism has uses beyond interface 
evolution, and may even use it for such purposes.  They may be disappointed 
that it is not more powerful (say, not mixins or traits) or that the syntax 
requires some boilerplate.  To them, I say: the glass is half full.

> 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
>>>
>
>