No, the problem is specifically because there are two objects/classes that are identical for all but two fields, hence the extension in the first place, but they do not implement this arbitrary thing called an Interface, despite their actual interface (as in, they have the same methods and properties - just different fields) being identical. Infact the two classes are even called exactly the same thing, just different namespaces.
I don't follow. You've said that their interfaces are identical, but that their fields are different? If the field isn't private (which it should be, by standard OOP practice), then it is part of the class's interface.
The example I gave pretty clearly illustrates the semantic problems with what you're trying to do, doesn't it? You've specified in the superclass A that whatever's contained in that property should satisfy certain predicates. The subclass B then adds to those predicates; however, A's interface requires that you be able to set the value to an object satisfying only the smaller set of predicates. If this is the case, then B's requirement that the property value satisfy the larger set of predicates is not met. Hence, covariance in this case is inconsistent.
In C# this "limitation" means that the base class methods, when accessed via a derived object, will update/interact with the derived object properties - at least, it should. It doesn't. The object maintains two instances of the field; one on base, one on the derived class that at first glance appears to be a wrapper on the base class, instead of an extended instance like it should be - and I might add, every other language manages.
Yeah, polymorphism isn't supported on fields; the only thing that could be overridden is the type, and that wouldn't make sense (as demonstrated above). Polymorphism is supported on properties, however, as their implementation can be overridden (though type variance isn't supported for the same reason), so just use them.
I think what you're describing there is member replacement, which is where rather than being overridden, the base member is 'hidden' by the new member. This is what happens when you don't use the
virtual/
override keywords, and is generally considered bad practice in C#, as it breaks polymorphism.
C# doesn't allow for covariance/contravariance in the specific cases of read-only/write-only properties because it would give rise to inconsistent behaviour (
"I can override the type of a property with only a getter but not one with a setter as well!?"). I don't like this decision very much but there ain't nothing I can do about it
I've read Buu Nguyen's blog on this very subject, and it leaves me thinking "So, you've disallowed covariance/contravariance simply because you don't want developers to cause an error in
their code.. who the hell are you you patronise so blatantly?"
They've disallowed it because it's necessary in order for C#'s static typing system to be self-consistent. If you don't like static typing, then fair enough, but don't knock C# for not giving a broken implementation of it!
I'm going to bleat about Smalltalk again, because quite frankly it rocks
p) and has been doing what .NET (and Java) have been unable to do for 50 years; it sensibly handles these kinds of problems by allowing you, the developer, to shoot yourself in the foot every now and then, and to actually learn from it.
This error/problem with .NET does nothing of the sort, it just leaves me confused, and asking "What they hell were they thinking?"
You seem to have a lot of hate for statically typed languages, but I use both statically and dynamically typed languages and I've honestly never encountered any problems with them. I find that static typing is useful (linguistic limitations aside) because it enforces semantic consistency as well as preventing potential runtime errors.
