Support for Polymorphism

[BierDav]

Is your feature request related to a problem? Please describe.
We have some dto's that share a few properties which is sometimes useful to have an interface or abstract class for and currently there is also no problem when doing this like in this example:

@Serializable
data class Foo(
    val bar: String,
    override val name: String
) : Named

@Serializable
data class Bar(
    val foo: String,
    override val name: String
) : Named

interface Named {
    val name: String
}

But unfortunately we do not get the inheritance information in our documentation. which would be quite nice.

Describe the solution you'd like

For interfaces and abstract classes an additional schema should be generated with their corresponding fields which than can be inherited using allOf in the documentation.

It is important that we get an setting for this behavior to be able to opt out of the new behavior or vice versa.

[brizzbuzz]

It is important that we get a setting for this behavior to be able to opt out of the new behavior or vice versa.

could you expand on this? It’s not clear to me from the example what you’re aiming to do. It seems a bit strange to want to expose data type composition details to the end user assuming that the actual data class used for the endpoint is a singular concrete implementation.

[BierDav]

The goal is that on the client I can also get Named as an own type. This is important when working with statically typed languages, where you want to get either a Foo or a Bar, but you don't have union types.

I think we should consider to, add a option to type enritchments where you can specify interfaces that should be resolved on their own, so that one gets fine grained control over this behavior, because there is a fair chance of unwanted side effects when working with third party dto's

[brizzbuzz]

Wouldn't the more idiomatic kotlin solution here be to use a sealed interface?

If you want to implement a solution for this I'd be happy to take a look at it, but there's almost no chance that I'll pick this work up myself.

[brizzbuzz]

But it's also worth noting that the maven team for some reason revoked my publishing credentials as a part of their move to a new infrastructure and trying to get it resolved was a huge pain so I can't even publish this library (or any libraries) at the moment :/

[BierDav]

Wouldn't the more idiomatic kotlin solution here be to use a sealed interface?

I don't think that we have to require to interfaces to be sealed because of the technical perspective, it shouldn't make a difference. If the developer decides to make it sealed because of his own design choices this should work too.

If you want to implement a solution for this I'd be happy to take a look at it, but there's almost no chance that I'll pick this work up myself.

Okay no problem. Maybe I have some time left over in the next weeks to implement this

[BierDav]

But it's also worth noting that the maven team for some reason revoked my publishing credentials as a part of their move to a new infrastructure and trying to get it resolved was a huge pain so I can't even publish this library (or any libraries) at the moment :/

Sounds bad how long do you think will it last until you can publish again?