Interface inheritance and duplicate fields

[jakubfijalkowski]

Since we support inheritance on the C# side, but want to convert it to "extension", we need to prevent the following case:

interface A { int PropA { get; set; } }
interface B { int PropA { get; set; } }
class C : A, B { public int PropA { get; set; } }

Currently, both A and B will have PropA. C won't, but it will extend both A and B and the resulting type will need to support both. That is wrong as we don't really know which PropA we are talking about. And if these two differ in type, e.g. when they are done like this:

interface A { int PropA { get; set; } }
interface B { string PropA { get; set; } }
class C : A, B { int A.PropA { get; set; } string B.PropA { get; set; } }

or like that

interface A { int PropA { get; set; } }
interface B { string PropA { get; set; } }
class M : A { public int PropA { get; set; } }
class C : M, B { new public string PropA { get; set; } }

we have totally undecidable case.

I suggest blocking this - i.e. when any DTO has a duplicate property when "flattened", reject it. What are your thoughts?

[konowrockis]

Out of curiosity is C even serializable/deserializable? Will an exception be thrown when trying to serialize/deserialize?

For the actual answer, I think we have to block. This basically shouldn't ever happen, so I think it always indicates an error on human side (or does it?) and should be blocked when trying to generate contracts.

[jakubfijalkowski]

Out of curiosity is C even serializable/deserializable?

It depends on the case. The one with two explicit implementations will serialize to {} and will deserialize to default values (so 0 and null). The one with M class will just work with the shadowed property (so string).

This basically shouldn't ever happen, so I think it always indicates an error on human side (or does it?) and should be blocked when trying to generate contracts.

It does make sense on the C# side, but does not make any sense outside of it so I completely agree with your reasoning here.