Superclasses for inline classes

[Dan Smith]

Yes, it is totally on the table that the language model doesn't bother to introduce an implicit class or interface above the inline class, and instead we're talking about two types derived from a single class declaration.

No matter what choice we make there, there's a separate question of whether inline classes can extend other classes, and I'm arguing that there are some good reasons that they should.

(There's also the question of how a 'ref' type gets compiled, nevermind what the language model says, and whether an abstract class would be a useful tool for that purpose.)

> On Dec 19, 2019, at 2:51 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> It occurs to me that we may have jump into the conclusion that we should use inheritance/implementation a little to fast.
> At least, i think it worth exploring another complementary option.
> 
> In Java, you have several ways to have subtyping,
> saying a FooInline is a subclass FooInline.ref is one way,
> but using wildcard is another one, if Foo<?> can be a template classes with Foo<inline bit> the inline.
> 
> It will not solve the retrofitting of java.lang.Number so it's a complementary approach but it can solve the retrofitting of java.lang.Integer in a better way than to use subclasses.
> 
> Let say java.lang.Integer is a template class, but not a template class over a type like a specialized generics are but a template class over the inline bit.
> In that case java.lang.Integer can have two specializations, one is an indirect type, the result of new Integer(8), and one is an inline type the result of Integer.valueOf(8).
> 
> The nice properties of this organization are:
> - object.getClass() will return Integer.class for both specializations (it's not the same species but it's the same class).
> - java.lang.Integer can still be final (because final means no subclass but not no subtype).
> 
> Rémi
> 
> 
> 
>