Defender Extension Methods -- Resolution and Invoccation

[Brian Goetz]

We considered this.  But C# extension methods have a HUGE problem -- they are 
static compiler tricks, and therefore an implementation cannot provide a 
better implementation than the one provided.  (You are probably reacting more 
to the fact that that they are use-site instead of declaration-site, and 
therefore do not "pollute" the interface since extensions are injected under 
the client's control rather than the library maintainer's.)

On 8/4/2010 6:12 PM, Paul Benedict wrote:
> 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
>
> On Wed, Aug 4, 2010 at 4:58 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto: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
>      >
>
>