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 <fo...@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 > > > >
