Formal model for defender method resolution

[David Holmes]

Neal Gafter said the following on 02/02/11 17:45:
> On Tue, Feb 1, 2011 at 10:57 PM, David Holmes <David.Holmes at oracle.com 
> <mailto:David.Holmes at oracle.com>> wrote:
> 
>     Neal Gafter said the following on 02/02/11 16:30:
> 
>         The same situation can occur with classes today:
> 
>         *class A<T> {
>          public T m() { ... }
>          public abstract String m();
>         }
>         class D extends A<String> {
>         }
>         *
> 
>         In this case the inherited non-abstract m implements the
>         inherited abstract
>         m.  It seems that we should allow the same thing for interfaces: a
>         (non-overridden) inherited concrete method should be capable of
>         implementing
>         an inherited abstract method.
> 
> 
>     Is this is an example we should strive to emulate? It seems an
>     extreme quirk of generics. Is there a realistic use-case for this?
> 
> 
> This is not specific to generics.  A more vanilla example is this:
> 
> *interface A { void f(); }
> 
> class B {
>    public void f() {}
> }
> 
> class C extends A implements B {
>   // B.f implements A.f
> }
> *

I presume you mean:

class C extends B implements A {

> You might not like these semantics, but I think it better to be 
> consistent with them than make up new and different semantics for 
> defender methods.

Ok I see the analogy but I think there is a difference between 
inheriting a concrete implementation from a superclass and inheriting a 
default implementation from an interface.

David