Why GetHashCode is in Object class?

Question

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 interfa

Answer 1

It was a design mistake copied from Java, IMO.

In my perfect world:

• ToString would be renamed ToDebugString to set expectations appropriately
• Equals and GetHashCode would be gone
• There would be a ReferenceEqualityComparer 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 overridden
• Objects wouldn't have monitors associated with them: Monitor 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.

Answer 2

Just a guess, but the garbage collector may store hashtables of some objects internally (perhaps to keep track of finalizable objects), which means any object needs to have a hash key.

Answer 3

GetHashCode is in object so that you can use anything as a key into a Hashtable, a basic container class. It provides symmetry. I can put anything into an ArrayList, why not a Hashtable?

If you require classes to implement IHashable, then for every sealed class that doesn't implement IHashable, you will writing adapters when you want to use it as key that include the hashing capability. Instead, you get it by default.

Also Hashcodes are a good second line for object equality comparison (first line is pointer equality).

Answer 4

1. So anything can be keyed on. (Sorta)
2. That way HashTable can take an object vs something that implements IHashable for example.
3. To Drive simple equality comparison.

On objects that don't implement it directly it defaults to .NET's Internal Hash Code which I believe is either a unique ID for the object instance or a hash of the memory footprint it takes up. (I cannot remember and .NET Reflector can't go past the .NET component of the class).

Answer 5

If every class has GetHashCode you can put every object in a hash. Imagine you have a to use third party objects (which you can't modify) and want to put them into ab hash. If these objects didn't implement you fictional IHashable you couldn't do it. This is obviously a bad thing ;)

Answer 6

It allows any object to be used as a key by "identity". This is beneficial in some cases, and harmful in none. So, why not?