Make it easier to work with class hierarchies

[Daniel-Svensson]

Problem

Union types in polytype do not map cleanly to class hierarchies, and does not currently match cleanly KnownType attribute behaviour

• If you only place DerivedTypeAttribute / KnownTypeAttribute on the base class , then derived types will not know of further derived types.

• If you instead place DerivedTypeAttribute on all level of the class hierarchy you will get unions of unions of unions
  , where serialization of a nested type might use several layers of "type" information

  In my case I I would get ["Derived2", ["Derived2", {actual class data}

Apart from serialization I like the concepts of the library and hope to be able to use to replace som existing custom reflection code

Background:

I am working with getting serialization based on PolyType to work with existing code bases, many currently using DataContract based serialization.
Where KnownTypeAttribute on the base type is good enough to get good serialization support even on derived types.

Workaround:
Yes it is possible to work around by using for example Nerdbank.MessagePack and manually discover type heirarchies without polytype and then setup all class hierarchies manually, but that

Suggestion of how it could work

• A derived class will inherit KnownTypeAttribute (for types that can be assigned to that type).
  • This is the expected behaviour if you use KnownTypeAttribute and I think it would make sense for DerivedTypeShape as well
• Even if a derived type is a union type, the parent's UnionCase should refer to the object shape
  • At least for the case where (DerivedTypeShape's are inherited ) OR (KnownTypeAttribute is used)

Note: Following code uses PolyType attributes, the original case used [DataContract] and [KnownType]

[GenerateShape]
[DerivedTypeShape(typeof(Derived1))]
[DerivedTypeShape(typeof(Derived2))]
public partial class Base
{
    public int Id { get; set; }
}

[GenerateShape]
public partial class Derived1 : Base
{
    public string derived1 { get; set; }
}

[GenerateShape]
public partial class Derived2 : Derived1
{
    public string derived2 { get; set; }
}

[Fact]
public void TestDerived()
{
    var typeProvider = ReflectionTypeShapeProvider.Default;

    ITypeShape<Base> baseShape = typeProvider.GetTypeShapeOrThrow<Base>();
    ITypeShape<Derived1> derived1 = typeProvider.GetTypeShapeOrThrow<Derived1>();
    ITypeShape<Derived2> derived2 = typeProvider.GetTypeShapeOrThrow<Derived2>();

    // Both base and derived1 should know about Derived2 and are union types
    // The UnionCase type of base should point to the actual underlying "Derived1" type, not the union type of "Derived1"
    IUnionTypeShape<Base> baseUnion = Assert.IsType<IUnionTypeShape<Base>>(baseShape, exactMatch: false);
    IUnionTypeShape<Derived1> derivedUnion = Assert.IsType<IUnionTypeShape<Derived1>>(derived1, exactMatch: false);

    Assert.IsNotType<IUnionTypeShape<Derived2>>(derived2, exactMatch: false);
    Assert.IsType<IObjectTypeShape<Derived1>>(baseUnion.UnionCases[0].UnionCaseType.Kind, exactMatch: false);
    Assert.IsNotType<IUnionTypeShape<Derived1>>(baseUnion.UnionCases[0].UnionCaseType, exactMatch: false);

    // Derived1 should be a union type with one case, which is Derived2
    Assert.Single(derivedUnion.UnionCases);
    Assert.IsType<IObjectTypeShape<Derived1>>(derivedUnion.UnionCases[0].UnionCaseType, exactMatch: false);
    Assert.IsNotType<IUnionTypeShape<Derived1>>(derivedUnion.UnionCases[0].UnionCaseType, exactMatch: false);
    Assert.Same(derived2, derivedUnion.UnionCases[0].UnionCaseType);
}

[eiriktsarpalis]

PolyType echoes the semantics of System.Text.Json and not DataContractSerializer, meaning that subtypes do not inherit polymorphic configuration from their supertypes. The reason is ambiguity when different supertypes contain conflicting configuration. This is true both in classes, where different types in the linear hierarchy specify different attributes but it's also the case for interfaces where one interface type can derive from multiple polymorphic parents.

[Daniel-Svensson]

PolyType echoes the semantics of System.Text.Json and not DataContractSerializer

That is fine, but you already have something that in my opinion is better that would support both worlds with some small tweaks to KnownTypeAttribute handling. System.Text.Json's attribute handling and ignorance of existing attributes are not the most developer friendly in my experience, even if later versions have made good progress, and I think you can do better.

1. Are you open to consider/discuss the support for KnownTypeAttribute only so that existing classes using DataContract would work well with polytype?

I have a local branch with this implemented to 90%, but I am gonna wait to have some feedback from how it would affect serializers such as Nerdbank.MessagePack first. And it would need some thoughts about how to handle the case where the BaseType have DerivedTypeShapeAttribute, currently I stop and ignore it.

2. Do you have any example were this could lead to problems?

I would expect something similar to how KnowTypeAttribute is used withing the ecosystem today where only valid derived types would be recognised, maybe even with the limitation that the "inheritance" part would apply to the base type only (and not interfaces).