Question

The documentation for -hash says it must not change while a mutable object is stored in a collection, and similarly the documentation for -isEqual: says the -hash value must be the same for equal objects.

Given this, does anybody have any suggestions for the best way to implement -hash such that it meets both these conditions and yet is actually calculated intelligently (i.e. doesn’t just return 0)? Does anybody know how the mutable versions of framework-provided classes do this?

The simplest thing to do is of course just forget the first condition (about it not changing) and just make sure I never accidentally mutate an object while it’s in a collection, but I’m wondering if there’s any solution that’s more flexible.

EDIT: I’m wondering here whether it’s possible to maintain the 2 contracts (where equal objects have equal hashes, and hashes don’t change while the object is in a collection) when I’m mutating the internal state of the object. My inclination is to say ‘no’, unless I do something stupid like always return 0 for the hash, but that’s why I’m asking this question.

Answer 1

Interesting question, but I think what you want is logically impossible. Say you start with 2 objects, A and B. They’re both different, and they start with different hash codes. You add both to some hash table. Now, you want to mutate A, but you can’t change the hash code because it’s already in the table. However, it’s possible to change A in such a way that it .equals() B.

In this case, you have 2 choices, neither of which works:

1. Change the hashcode of A to equal B.hashcode, which violates the constraint of not changing hash codes while in a hash table.
2. Don’t change the hashcode, in which case A.equals(B) but they don’t have the same hashcodes.

It seems to me that there’s no possible way to do this without using a constant as a hashcode.