Formal model for defender method resolution

[Brian Goetz]

> If a bare "default" keyword is not descriptive enough, then maybe the following is more
> descriptive:
>
> interface A {
>    void m() default Defaults.m;
> }
>
> interface B {
>    void m() default super;
> }

While we're having a nice syntax bike-shed paint, I'll just point out 
that it would be nice if the syntax in the default were the same as the 
syntax in a clarifying override, which is currently:

   intf A { void m() default X.a }
   intf B { void m() default X.b }
   class C implements A, B {
     void m() { A.super.m(); }
   }

I am much more interested in getting a clean semantics of what it 
*means* to remove a default, and how it might play into default 
resolution in cases like:

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

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?

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

I'd like to start with the simplest possible design for defenders and 
then work up from there.  We are clearly nowhere near the simplest 
possible design yet...