The URL you referenced says [quote] WARNING: When an object is stored in a hash table, an application should never change the object in a way that will change its hash code. If you do so, the object will thenceforth be in the wrong bucket. [end quote]
I fear that MS did not make it clear enough how they want things to work in the case of a mutable object -- the docn says one thing, various blogs (and msgs in this forum) say something else. At 12:13 PM 7/3/2005, JimK wrote >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 J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
