(2003 to 2005)


Sat Mar 6 19:04:00 UTC+1100 2004


The doco for IComparable.CompareTo says:

By definition, any object compares greater than a null reference (Nothing in Visual Basic); and two null references compare equal to each other.

What of ValueType? See, it uses boxing to allow for derivation from Object, but is it really an Object? Perhaps yes. Perhaps no.

Anyway, it also says:

The parameter, obj, must be the same type as the class or value type that implements this interface; otherwise, an ArgumentException is thrown.

So, which is the stronger rule? If I pass a null reference for comparison against a ValueType then do I say “this parameter is not of correct type” (because a ValueType is not a 'reference type' and can not be allocated a 'null reference') or do I say “this boxed ValueType that is behaving like an Object will sort higher than this null reference”?



Why do I continually become un-amazed by .NET? You know, I *want* to love it, but it really isn't being very accommodating.

Resorting to implementation for my specification I find that SqlBoolean.CompareTo(..) will throw on a null reference. Of course, I found another bug in Mono (assuming that MS has the authoritative implementation). Also, the NullableTypes open source library behaves the same way that Mono does (but not suspiciously so).

Some people might accuse me of breaking ranks by 'going my own way', but in the face of all this, can you blame me?

Technically, based on the doco, each implementation could be considered correct. If I can get two 'correct' yet 'different' behaviours when implementing an 'interface' then what sort of a 'contract' have I defined? It wouldn't stand up in court that's for sure.

Perhaps Microsoft should get their legal team onto the framework design team, I doubt they would have let something as blatent as this slip through the cracks.


Copyright © 2003-2005 John Elliot