Formal model for defender method resolution

[David Holmes]

Peter Levart said the following on 02/02/11 23:55:
> So when we are talking about method C.m() in:
> 
> interface A { void m() default X.m; }
> 
> interface C extends A { void m() default none; }
> 
> then all the compiler can deduce from the source is that C.m() is
> abstract (as any concrete implementation of C must provide m's
> implementation). What can compiler say about the semantics of C.m?
> Nothing much besides that the author of C choose that the default
> implementation of A.m is perhaps often not suitable for implementors
> of C. The semantics of A.m and C.m are potentially conflicting, yes,
> but should compiler barf on that when both interfaces are used in
> implementation:
> 
> class F implements A, C {}

Not in this case, because implementing C completely encompasses 
implementing A so the "A" is redundant. This is my preferred semantics 
for this. The problem arises when you then add

interface B extends A { void m() default X.b; }

and

class G implements B, C { // or A, B, C
   // what is G.m() ?
}

Now the compiler has a conflict between B's claim that m() should 
default to X.b, and C's claim that m() should be abstract. So the 
compiler should quite rightly reject G and force the programmer to 
resolve the conflict.

If we have:

interface D extends B, C { }

then I suggest, for simplicity and consistency that the compiler also 
reject this.

David

> 
> Regards, Peter