Formal model for defender method resolution

[Neal Gafter]

On Tue, Feb 1, 2011 at 8:41 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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(); }
>   }
>

Yes, many of us have pointed out the benefits of writing the body inline.


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

Yes.  To see why this is the only reasonable resolution, make every override
in your example covariant.

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

Perhaps, but specifying the most general case (covariant returns) leads to
reabstraction being the simplest semantics that are sound.