Defender Extension Methods -- Resolution and Invoccation

[Rémi Forax]

Le 05/08/2010 00:12, Paul Benedict a écrit :
> Since interfaces are pure contracts, providing a default *implementation*
> smells of a philosophical problem to me. It seems hack-ish. I also don't
> have a better answer, but C# extension methods look more appealing.
>
> Paul
>    

You can't override a C# extension method.

C# extension method is a compiler hack,
Java extension method is a VM hack.

Rémi

> On Wed, Aug 4, 2010 at 4:58 PM, Brian Goetz<brian.goetz at oracle.com>  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
>>>
>>>        
>>
>>      
>