Formal model for defender method resolution

[Brian Goetz]

>> 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.

Which means you would also reject

   class X implements A, B { }

on the same basis.

This is ground that's already been covered, but I feel strongly that X 
here must compile and select B's defender.  It is a common idiom for 
people to write things like

   class X implements List, Collection { ... }

and historically this has been a no-op.  We don't want to break the 
existing classes that do this by adding conflicting defenders to new 
methods in Collection that whose defaults are overridden in List -- the 
whole goal here is to be able to add new defended methods to interfaces 
and not break implementations.

This is the reason for the "pruning" features in both the defender 
writeup and the formal model.

> Certainly my previous example of getValue() and
> getEstimatedValue() where getValue defends to getEstimatedValue is a
> valuable feature.

There are an infinite number of valuable potential features, but we're 
not going to add them all (and can't, since many of them might conflict 
with other valuable features).  "Valuable" is also too low a bar.