Formal model for defender method resolution

[Neal Gafter]

On Wed, Feb 2, 2011 at 12:57 AM, Peter Levart <peter.levart at marand.si>wrote:

> On 02/02/11, David Holmes wrote:
> > Neal Gafter said the following on 02/02/11 16:30:
> > > So far so good.  But none of these examples prevent *any *attempt to
> inherit
> > > from the interface, they only prevent inheriting from the interface
> without
> > > overriding the method family in question.  That's no different from any
> > > other interface method today, except for the fact that the intent of
> these
> > > new defender methods is that they not demand to be implemented directly
> by
> > > classes that implement them.
> > >
> > > For the specific case of
> > >
> > >    intf A { String m() default X.a }
> > >    intf B { String m() default X.b }
> > >    intf C extends A { String m() default none }
> > >    intf D extends A, B, C { }
> > >
> > > A class that implements D has a single, unique, non-overridden
> > > implementation for the method family (B.m), and it is a suitable
> > > implementation (i.e. the return type works) for the inherited abstract
> > > method.  So there doesn't appear to be any problem with that class, and
> > > therefore there should be no problem with these interfaces
>
> Neal, what happens to this interface:
>
>    inf F extends A, C {}
>
> Do implementations of F have to provide an implementation for m()?


I would think so.


> Do you consider that if a method is overriden in C then it doesn't matter
> if it is also mixed-in explicitly?


Yes.  Today, explicitly mixing in an interface that you otherwise already
implement has no practical effect on the compile-time meaning.


> Does anything in existing Java method resolution rules express that a
> "redundant" interface inheritance graph should be pruned in any way?
>

How would you be able to tell?