Formal model for defender method resolution

[Ali Ebrahimi]

Hi Brian,
do you mean "default none" as reabstraction?


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

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