GetHashCode override

  • Thread starter Thread starter Bill Mittenzwey
  • Start date Start date
B

Bill Mittenzwey

Ok, I've read in the docs, some books and some articles by prominant
dotneters about how to override GetHashCode, but it still leaves me somewhat
puzzled.

I have a custom object which I want to be able to have sorted correctly in a
sortedlist/hashtable... For that to work correctly, I need to override
Equals(). Fair enough, otherwise the sort would not really know what
represents the value of my object. Then the compiler tells me that I need to
also override the GetHashCode. At first thought, it seems easy, just pass
the call on to my describing property ( a stirng) and it would seem to work.

Ah, but that seems to break the rules for GetHashCode. As I see it, I need
to guarantee that all objects which represent the same value return the same
Hash Code (fine so far), and I need to guarantee that once an object has
supplied a hash code, it will never change. Conflicts start here. What if I
have two objects which have there properties set to two different values,
and so have reported back two different hash values. Then a program changes
the property of one of the objects to be the same as the other. Now I have
two objects which represent the same value, but with two different hash
codes. I seem to be stuck in a catch-22 here. I have to have all objects
representing the same value return the same hash, but I can't change the
hash to make a changed object compliant. What if the objects I wanted to
sort were based off of a property like priority. It is reasonable to have
multiple objects with the same priority in a list, and I would want the
objects to be sorted in the list based off the priority. Also it is common
for a priority to change, in which case, I would want that object to move to
a different location in the list.

Can anyone explain this? Am I just misusing the lists?
 
Bill Mittenzwey said:
Ok, I've read in the docs, some books and some articles by prominant
dotneters about how to override GetHashCode, but it still leaves me somewhat
puzzled.

I have a custom object which I want to be able to have sorted correctly in a
sortedlist/hashtable... For that to work correctly, I need to override
Equals(). Fair enough, otherwise the sort would not really know what
represents the value of my object. Then the compiler tells me that I need to
also override the GetHashCode. At first thought, it seems easy, just pass
the call on to my describing property ( a stirng) and it would seem to work.
Yup.

Ah, but that seems to break the rules for GetHashCode. As I see it, I need
to guarantee that all objects which represent the same value return the same
Hash Code (fine so far), and I need to guarantee that once an object has
supplied a hash code, it will never change. Conflicts start here. What if I
have two objects which have there properties set to two different values,
and so have reported back two different hash values. Then a program changes
the property of one of the objects to be the same as the other. Now I have
two objects which represent the same value, but with two different hash
codes.
Click to expand...

As soon as types are mutable, you've got a problem whenever they're
stored in hash tables, sorted lists or whatever. Don't forget that
Equals will suddenly change as well - something that *was* Equal to
another thing possibly won't be any more.

Do you *definitely* need your property to be settable?
 
After some thought, I would consider making that particular class a one-time
write class, but what of the situation I mentioned in the first message,
what you want to sort on is a priority of importance of tasks or something
where the priority is subject to change?
 
...but what of the situation I mentioned in the first message,
what you want to sort on is a priority of importance of tasks
or something where the priority is subject to change?
Click to expand...

Then a hash table is probably not your best container, but be that as it
may, why not pull the item out of the list, change the priority and re-
insert it?

-- Rick
 
Bill Mittenzwey said:
After some thought, I would consider making that particular class a one-time
write class
Click to expand...

Right - in which case, it would be best to put that one-time-write in
the constructor, or *very carefully* document that it should be set
*before* putting it in a hash table etc.
but what of the situation I mentioned in the first message,
what you want to sort on is a priority of importance of tasks or something
where the priority is subject to change?
Click to expand...

Then I wouldn't make the priority part of the equality contract, I
suspect. I very rarely override Equals.
 
Back
Top