Inline Classes and extends

[John Rose]

On Dec 10, 2019, at 1:08 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> Is there any hope of rescuing superclass cases by converting the superclass
> to an interface?
> 
> I'm particularly thinking of java.time.ZoneId and it's subclasses
> ZoneRegion and ZoneOffset. ZoneId had to be an abstract class originally as
> there were no sealed types, but it could be converted to a sealed interface
> in the future if that was a compatible change. Then the two subclasses
> could be inline classes (which they logically are). It also assumes we can
> have package scoped inline classes.
> 
> I ask because the plan to convert the primitive box types to interfaces
> suggests ZoneId could be another candidate.

Yes, on a case-by-case basis, and probably in this caser.

There are some moves here we could do:
(a) make interfaces even more like abstract classes, or
(b) accept a class C as a super of an inline, if it’s enough like an interface.

(a) is a long-term trend; see default methods and then sealing,
both of which are tricks that used to be the sole property of
abstract classes.  This trend could be characterized as making
interfaces more concrete, more like abstract classes.

(b) is an option to explore *if we are forced to*.  The insight
here is that maybe an abstract inline class is permissible if,
like an interface, it is "abstract enough" to pass muster as a
reference view on more than one concrete inlines.  This
move could be characterized as allowing (some) abstract classes
to perform interface-like duties.

We are holding off from these moves, not because they haven't
been proposed yet, but because they do not yet seem to pay for
themselves, yet.  Future adventures like adapting ZoneId will
help us decide whether to change our tune about (a) or (b).

Note that a variation of (a) is already on the table, since Optional
will need to be migrated to an interface, in which case Optional
will have to behave like an abstract class relative to linkage
requests (invokevirtual, CONSTANT_Methodref) which originate
from old code that tries to treat Optional like an abstract class.

In the long term, I don’t think it would be wrong to end up with
interfaces and abstract classes looking very similar indeed.  But
we’ll have to get there by steps, I think, with each step clearly
motivated.

— John