What does reabstraction mean?

[Stephen Colebourne]

On 27 December 2011 14:23, Brian Goetz <brian.goetz at oracle.com> wrote:
> There have been some strong opinions stated here about the syntactic
> form used to denote reabstraction of a default method.  Let's take look
> at a somewhat deeper question: what *should* reabstraction mean in the
> context of an interface method?
>
> Concrete class methods can be reabstracted today:
>
> class A {
>     void m() { ... }
> }
>
> abstract class B extends A {
>     abstract void m();
> }
>
> class C extends B {
>     void m() { ... }
> }

I ask myself, what if Java supported muti-inheritance of classes, and
I wrote this:
 class D extends A, B { }

I think this should compile (in this imaginary Java version). D
extends A, so inherits m(). B requires that subclasses have an m()
available. Since D does, it should compile.

> The motivation is simple: a subclass can impose semantics which it has
> reason to believe the superclass implementation cannot provide, so it
> wants to veto the existing implementation and force a new one to be
> provided.

For the record, I don't think I've ever done this, so its probably rare.

> The current extension methods design calls for the ability to
> "reabstract" a default as well; the motivation is the same.  I'll use
> the more explicit "default none" to denote reabstraction here, for
> clarity.
>
> interface I {
>     void m() default { ... }
> }
>
> interface J extends I {
>     void m() default none;
> }
>
> But, with multiple inheritance, there are at least two realistic choices
> for what this means:
>
>  - Strong: reabstraction means "this class needs an implementation of
> m(), which must be provided by one of my subtypes."
>
>  - Weak: reabstraction means "this class needs an implementation of
> m(), but don't use the one(s) provided by my supertype(s)."

Given the multi-inhereit example, I'd choose "weak". "Strong" is a new
concept in Java, trying to knock out parents permanently, which seems
a little odd.

Stephen

> In the single-inheritance case, both of these collapse to being the same
> thing, so analogies with existing class reabstraction offer us little
> guidance here.  (With multiple inheritance, we also have to resolve how
> they should interact with other declarations in the hierarchy that are
> not related by subtyping, such as those that arise from "C extends A, B"
> structures.)
>
>
> Ignoring the details of how they fit into the language feature as it
> currently stands, which of these interpretations seems more compelling,
> natural, or powerful for the purposes of building safe and useful libraries?
>
>
>