Formal model for defender method resolution

[Stephen Colebourne]

On 1 February 2011 16:41, Brian Goetz <brian.goetz at oracle.com> wrote:
> intf A { String m() default X.a }
> intf C extends A { String m() default none }

Ignoring the syntax, anything extending/implementing A may provide
m(), while anything extending/implementing must provide an m().

> intf B { String m() default X.b }
> intf D extends A, B, C { }
>
> What now?  Do we barf because A and B are contributing conflicting
> defaults?  If we prune A from consideration (as I believe we should), do
> we barf because the "none" in C conflicts with the default in B?

E extends C, A is fine - the abstract contract from C is met by A.
F extends C, B is fine - the abstract contract from C is met by B.
G extends A, B is not fine - the contract from A clashes with that of B.
D has all three, the abstract contract from C is met by *at least one*
other definition, so is met. This leaves A and B, which then clash.

(and yes, I am saying that "extends B,C" is not the same as "extends A,B,C")

> And, secondarily, whether such a construct (which is analogous to, but
> distinctly separate from reabstraction) is actually useful enough to
> overcome the additional complexity?  ("Because its analogous with
> reabstraction" is way too low a bar.  One can justify any language
> feature, sensible or not, by that logic.)

True, but completeness would aid my understanding of the feature. eg.
I can call a non-declared interface method from an abstract class that
implements the interface, therefore, I should be able to defend to the
same interface method. Certainly my previous example of getValue() and
getEstimatedValue() where getValue defends to getEstimatedValue is a
valuable feature.

Stephen