I think we should step back to our Computer Science class and the definition of hash tables and hashing functions. Here's one "lecture": http://www.cs.berkeley.edu/~jrs/61b/lec/22 . By definition, a hashing function can return the same value for two different objects, so we can't argue about wanting uniqueness.
As for immutability, we need to separate the discussion of the FIRST generation of the hash code from subsequent generations. I hope we can agree that GetHashCode() is doing the correct thing the FIRST time. Now, what should it do the second time? We'll, this gets complicated when you're talking about objects instead of simple values. Think of the Dictionary in the above link. If you're going to use an object as the key value in a Dictionary (which might be implemented as a hash table), then each time you supply the object as a key you want the Dictionary to be able to find the same entry. The designers of GetHashCode() meet that requirement by having the object return the same hash code for all subsequent calls. A hash code isn't meant to represent the value of the object, it's just a compressed, short reference to the object. - Jim -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ian Griffiths Sent: Saturday, July 02, 2005 2:47 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] GetHashCode() method > special code needs to exist to ensure that once GetHashCode() > has returned a value, that object instance must always return > the same value from later GetHashCode calls. Nope. I know the docs say that GetHashCode must always return the same value, but they are wrong. See the "Documentation Rant" section in the second half of this: http://www.interact-sw.co.uk/iangblog/2004/06/21/gethashcode <snip> =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
