OK, this is really shitting me now.
This interface really seems to fall over for value types. Think about the code I showed last time:
Int16 s = 123;
Console.WriteLine(s.Equals(123)); // False
That really sucks. 123 does equal 123. The interface specification for Equals(Object) says: Determines whether two Object instances are equal.
I've always considered this interface is about 'value equality', but apparently it this also requires 'type equality'.
And what of null value equality? So tricky.
Does the value CAT not equal CAT because the font is different? In an OO world that supports only single inheritance why must I always rely on inheritance to determine 'type'? Particularly in the case of value types where I have no user specifiable inheritance at all.
My nullable type library isn't going to treat null like a database does I've decided. Treating null with TVL only makes sense when you operate over sets. When you are coding imperatively you really want boolean logic. If you don't know the value, you can't test for equality. So, most of my operator overloads throw on null values now, and they define two null values as not equal. This means that my nullable types can't be used as keys in a hash table, because two objects representing null will never be found. This makes sense, however, it breaks all sorts of rules in the specification. I'm doing it anyway, I don't think you can just ignore null values, but the framework doesn't cater for them, so I have to DIY. Obviously you can't key something with a null value, obviously a null value doesn't equal another null value. If you can define an implicit or explicit cast or conversion for a value type then why not allow for the conversion for the sake of determining equality or value comparison?
John.