Inline Classes and extends

[Brian Goetz]

As the document suggests, we are considering such treatment for Integer 
(and Number, ugh) and Optional.  While this surely has its own set of 
costs (supporting interface methods in `invokevirtual`, etc), this seems 
to be the lesser of evils compared to allowing inline classes to extend 
abstract classes (on which we'd need to imposes a complicated and 
hard-to-statically-check set of conditions.)  As you point out, if we 
have this tool in our box, then (combined with sealed types) it lets API 
designers compatibly evolve their APIs towards a more abstract 
representation, which seems like a beneficial direction.

There's no problem with non-public inline classes.  (The combination of 
public reference projection and private implementation class is expected 
to be a common one.)

On 12/10/2019 4:08 PM, Stephen Colebourne 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.
>
> Stephen
>
>
> On Tue, 10 Dec 2019, 18:24 John Rose, <john.r.rose at oracle.com> wrote:
>
>> On Dec 10, 2019, at 10:17 AM, August Nagro <augustnagro at gmail.com> wrote:
>>> One question I have is about `extends`. I understand that inline classes
>> cannot extend IdentityClass, but what about other inline classes? I have a
>> lot of classes that would make sense as inline, but are held back by their
>> superclass (which also could be inline).
>>
>> One thing you get with the extra indirection of reference objects
>> is layout polymorphism, the power to have one type which points
>> at two or more distinct layouts.
>>
>> If you get rid of the pointer (which is a must for inlines, so they
>> can “work like an int”), then you also lose the ability to represent
>> layout polymorphism.
>>
>> It’s like in C++ when you try to mix inheritance and by-value storage
>> of instances:  Stuff goes wrong, awkwardly.
>>
>> struct A { int x; }
>> struct B : public A { int y; }
>> A avar; avar.x = 1;
>> B bvar; bvar.x = 2; bvar.y = 3;
>> A anotheravar = bvar;  // what happened to the 3??
>>
>> — John