Formal model for defender method resolution

[Howard Lovatt]

On 2 February 2011 03:41, Brian Goetz <brian.goetz at oracle.com> wrote:

[snip]

> 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 assume you are suggesting:

interface IC extends A, B {
  void m() defaults A.super.m;
}

This seems perfectly reasonable.

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

I would suggest that D behaves exactly like:

class CD implements A, B, C {
  ...
}

 -- Howard.

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



-- 
  -- Howard.