Defender methods and reabstraction

[Collin Fagan]

*>
> // maybe
> interface B extends A {
>       @Override
>       void m() default super.m;  // or A.super.m
> }

You need that if you override the method to add doc comment.*

You would also need to do this if you wanted to change or remove the
annotations that apply to a method.
*
*interface A {
       *@XMElement*
       void m() default Stuff.foo;
 }

interface B extends A {
       @XMLTransient
       @Override
       void m() default super.m;  // or A.super.m
 }

or
interface B extends A {
       @Override
       void m() default super.m;  // or A.super.m
 }

Collin


On Thu, Dec 2, 2010 at 2:27 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

>  Le 02/12/2010 05:43, Brian Goetz a écrit :
> > It was pointed out to me the other day that the defender methods document
> does
> > not properly deal with removal of a default.  The intent all along was
> that
> > removal of a default should be analogous to reabstraction of a concrete
> method
> > by an abstract subclass.
> >
> > Syntactically, the logical way to remove a default would be to override
> the
> > method without a default:
> >
> > interface A {
> >       void m() default Stuff.foo;
> > }
> >
> > interface B extends A {
> >       @Override
> >       void m();
> > }
> >
> > It might be desirable to have a syntactic means of saying "same default
> as my
> > parent", which might look like:
> >
> > // maybe
> > interface B extends A {
> >       @Override
> >       void m() default super.m;  // or A.super.m
> > }
>
> You need that if you override the method to add doc comment.
>
> > We'll put that one on the "things to think about" list.
> >
> > Semantically, I think it makes sense to treat a reabstracted extension
> method
> > as having a "special" default.  This allows us to have a unified approach
> for
> > handling shadowed extension methods:
> >
> > interface A {
> >       void m() default Stuff.foo;
> > }
> >
> > interface B extends A {
> >       void m() default Stuff.moo;
> > }
> >
> > interface C extends A {
> >       void m();
> > }
> >
> > class X implements A, B {
> >       // m() is linked to Stuff.moo -- B default shadows A default
> > }
> >
> > class Y implements A, C {
> >       void m() { ... }
> >       // m() implementation required here
> >       // even though A is directly implemented
> >       // as reabstraction in C shadows default in A
> > }
> >
> > This preserves the linearization-by-topological-sort property in both
> cases
> > "re-implementing" A is a no-op because X and Y implement more specific
> > interfaces (B and C extend A, so re-implementing A has nothing left to
> offer
> > to X and Y, and therefore can be ignored.)
> >
> > I'll add this to the next round of the document.
>
> I don't understand your point, here.
> The spec already says that if X implements A and B and B extends A, then
> only default methods from B should be considered.
>
> Rémi
>
>
>