Is it possible to have the following: ```abstract ...

# announcements

[maxmello]

Is it possible to have the following:

abstract class A<T : A<T>>(
    val id: Id<T>
)

class B(id: Id<B>) : A<B>(id)
class C(id: Id<C>) : A<C>(id)

I want to have polymorphism in a DB model, and the library provides type safe Id with generics. I want the superclass to have the id property and to restrict it to be of any subclass of itself. For this I have the A<T : A<T>> definition on top. Now, a subclass passes in its own type and only allows id to be of that type, making sure I never have Id<C> in a B class.

But when trying to use that type system, I have the problem of recursive definition of the parameter of A. For example when mapping a list of instances of objects holding subclasses of A, I need to specify the type variable like this:
SomeClassHoldingASubclasses(…) => SomeClassHoldingASubclasses<A<A<A ... > > >
It is not possible to do it like this: SomeClassHoldingASubclasses<*> “projections are not allowed on type arguments of functions and properties”

If I remove the type variable from A, I cannot pass an id : Id<B> to the constructor of A.

I’m trying to get this to work for quite some time now, but are these polymorphic / self-referencing type variables even possible? Should I use in
or out (I tried but that also went weird fast)?

[Andrzej]

Do you have any specific example of SomeClassHoldingASubclasses, where this problem occurs?

[Dennis]

arrayOf<...>()
The question is why do you want to keep these objects in the same list? Aren't they different? Do you get any benefit from having a common parent class?

[maxmello]

The benefit of having a common parent class is polymorphic deserialization with @JsonSubTypes annotation from jackson.
I think I might have found the solution, I replaced some instances of other related classes, which I also parameterized with <T: A<T>> with just using A<*> in place directly. Now the errors are gone. Let’s see if it actually works out or not

[maxmello]

I tried to simplify the problem for here, In practice something like over 10-15 classes are involved which makes it kinda hard to explain and anybody to find the actual problem for me. I just wanted to know if it is theoretically possible to have this A<T: A<T>> structure, but as it at least compiles I guess I should expect that it will work

[Dennis]

Well it works, you probably just can't use it as a common denominator in arrays/lists. I'm coming from a C# background, so I'm not sure if Java offers a way to get around this for lists etc.