Formal model for defender method resolution

[Peter Levart]

On 02/02/11, Peter Levart wrote:
> > > 
> > > I have to disagree with you there. The semantics for A.m, B.m and C.m 
> > > are potentially different, so what semantics does D.m provide ? 
> > 
> > I would say (considering my suggested semantics of "default none") that C.m does not provide any semantics (it just forces the implementor or a mixer to provide one). So "D" here is "a mixer" that mixes in A.m and B.m defaults, which are, unfortunately, conflicting.
> 
> Ok, you may say that by stating "void m() default none", C says that any semantics provided by overriden methods should be ignored, even if it comes from explicitly mixed-in paths. But should we grant C such power? Isn't that D's concern? D can choose to mix-in the semantics of A.m (by extending A explicitly although it already extends C which extends A) or to ignore any inherited semantics (by overriding and stating "default none").
> 

I found myself saying that abstract methods don't provide any semantics. That's wrong! They do (usually in the form of Java-docs). But currently, Java compiler can't and doesn't check the conflict-ness of the multiply inherited semantics. So for example the following is perfectly compilable:

public class Impossible<E> implements Set<E>, List<E> {
...
}

...although the semantics of some methods overridden from both interfaces are conflicting.

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


Regards, Peter