What does reabstraction mean?

[Neal Gafter]

Even in the single-inheritance case, it is possible to inherit a method
that becomes an implementation of an abstract method (using generics where
methods unify).  And with the presence of multiple inheritance through
interfaces (but with only abstract methods in interfaces), one can
similarly inherit an implementation for an interface method from a
superclass that doesn't implement the interface.  It would be strange for
these mechanisms to break down in the presence of reabstraction, so I
suggest that what you call weak abstraction is the right way to specify it.

On Tue, Dec 27, 2011 at 6:23 AM, 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() { ... }
> }
>
> 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.
>
> 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)."
>
> 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?
>
>
>
>