Formal model for defender method resolution

[Neal Gafter]

On Tue, Feb 1, 2011 at 10:57 PM, David Holmes <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
}
*

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.