Defender methods and reabstraction

Rémi Forax forax at univ-mlv.fr
Thu Dec 2 00:27:31 PST 2010


  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



More information about the lambda-dev mailing list