Confused by GetHashCode() documentation

[Stephan Keil]

Hi all,

I am somewhat confused by the Object.GetHashCode() documentation. What I am
looking for, is a hash code, which is bound to the _identity_ of an
object, not to it's _value_ (see other thread "Object identity").

In the documentation, the statement
"The hash function must return exactly the same value regardless of any
changes that are made to the object"
suggestes that the hash code is bound to an object _identity_ (that would
be useful for me).

But this contradicts to the statement
"If two objects of the same type represent the same value, the hash
function must return the same constant value for either object"
(saying that the hash code is bound to the object's _value_) and to the
examples in the documentation, e.g.
public struct Int32 {
public int value;
//other methods...
public override int GetHashCode() { return value; }
}

Which statement is right? Or where am I wrong? (I assume that the hash code
refers to the value, not the identity. This - unfortunately - would not
solve my problems, see other thread "Object identity").

- Stephan

[Jon Skeet [C# MVP]]

Stephan Keil <St**********@gmx.de> wrote:

I am somewhat confused by the Object.GetHashCode() documentation. What I am
looking for, is a hash code, which is bound to the _identity_ of an
object, not to it's _value_ (see other thread "Object identity").

In the documentation, the statement
"The hash function must return exactly the same value regardless of any
changes that are made to the object"
suggestes that the hash code is bound to an object _identity_ (that would
be useful for me).
The documentation is unfortunate, IMO. To me, it makes perfect sense
that if the value changes, the hash code should change too. You then
need to put a warning in Map etc that if you use a mutable object as a
key, you shouldn't change it afterwards or you might not be able to
find it again.

Of course, this partly depends on the whole business of System.Object
having a GetHashCode() method in the first place. Just using
IEqualityComparer would have probably been better, so that only those
classes which wished to advertise themselves as suuitable for hashing
had hash codes in the first place. (Classes could have implemented
providers for other classes, of course.)
But this contradicts to the statement
"If two objects of the same type represent the same value, the hash
function must return the same constant value for either object"
(saying that the hash code is bound to the object's _value_) and to the
examples in the documentation, e.g.
public struct Int32 {
public int value;
//other methods...
public override int GetHashCode() { return value; }
}

Which statement is right? Or where am I wrong? (I assume that the hash code
refers to the value, not the identity. This - unfortunately - would not
solve my problems, see other thread "Object identity").

Yes - it basically makes mutable objects return constants as their
hashcodes, which is plainly daft.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too