Why GetHashCode is part of the Object class? Only small part of the objects of the classes are used as keys in hash tables. Wouldn't it be better to have a separate interface which must be implemented when we want objects of the class to serve as keys in hash table.
There must be a reason that MS team decided to include this method in Object class and thus make it available "everywhere".
It was a design mistake copied from Java, IMO.
In my perfect world:
ToString
would be renamed ToDebugString
to set expectations appropriatelyEquals
and GetHashCode
would be goneReferenceEqualityComparer
implementation of IEqualityComparer<T>
: the equals part of this is easy at the moment, but there's no way of getting an "original" hash code if it's overriddenMonitor
would have a constructor, and Enter
/Exit
etc would be instance methods.Equality (and thus hashing) cause problems in inheritance hierarchies in general - so long as you can always specify the kind of comparison you want to use (via IEqualityComparer<T>
) and objects can implement IEquatable<T>
themselves if they want to, I don't see why it should be on Object
. EqualityComparer<T>.Default
could use the reference implementation if T
didn't implement IEquatable<T>
and defer to the objects otherwise. Life would be pleasant.
Ah well. While I'm at it, array covariance was another platform mistake. If you want language mistakes in C#, I can start another minor rant if you like ;) (It's still by far my favourite language, but there are things I wish had been done differently.)
I've blogged about this elsewhere, btw.