Defender Extension Methods -- Resolution and Invoccation

Paul Benedict pbenedict at apache.org
Wed Aug 4 15:12:41 PDT 2010


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


More information about the lambda-dev mailing list