Fix issue with modeling inheritence

Cat and Dog have an Animal base model but we generate type AnimalUnion = Animal | Cat | Dog instead of type Animal = Cat | Dog

In these cases the base model (e.g. Animal) contains common properties from the server, but never is actually returned. This is a workaround for the lack of anyOf and oneOf in the modeler.

For now an x-ms- property that omits the base type would be sufficient.

[craigsmitham]

I agree the type Animal = Cat | Dog; would be appropriate when seeking to model oneOf/anyOf. I wish we had oneOf/anyOf support, but that doesn’t seem to be the scope of this issue.

If we are going to infer an inheritance hierarchy using allOf, to be consistent I think one of the options that can be returned in the union type should be the base class. It may or may not be abstract, depending on the individual API implementation.

The more I think about this though, is modeling hierarchical inheritance appropriate at all when using allOf? It seems like a nice way to share properties within API definitions, but is not intended to model hierarchical inheritance.

---

Bottom line: I’m all for the original proposed solution for the case when allOf is used to model inheritance (e.g. a x-ms- property). However, I just want to highlight he need to also ensure the discriminator field is generated to support type narrowing (as @xirzec 's comment appears to do).

[xirzec]

@jrpedrianes not without wrapping the generated client and doing something clever.

@bterlson how does CADL solve this problem? I feel like the answer for an extensible union has to be in the implicit existence of an unknown kind.