Re: When do I need to override hash?
Re: When do I need to override hash?
- Subject: Re: When do I need to override hash?
- From: Jean-Daniel Dupas <email@hidden>
- Date: Fri, 21 Aug 2009 11:07:26 +0200
Le 21 août 2009 à 10:55, Alastair Houghton a écrit :
On 21 Aug 2009, at 05:44, Quincey Morris wrote:
On Aug 20, 2009, at 20:51, Seth Willits wrote:
The documentation, nor did many others' comments on this topic,
make it clear that the mutability is only a problem for the
*keys*. Others and the docs talk about (paraphrasing) "putting an
object into a collection", not "using an object as a key in an
associative collection."
Yes. I believe Alastair misspoke.
Not at all.
hat he said is actually 99.9% true, but establishes a different
point. The keys in a dictionary (or other keyed collection, like a
map table) need to be immutable objects, but that's unrelated to
the hash. Mutability in the keys would be bad, hash or no hash.
(Newbies please ignore the next bit.)
Well... somewhat perversely, what matters in Cocoa is the notional
"value" of the key (as determined by -isEqualTo:, -hash and possibly
-compare:). The *actual* contents don't matter, so it's OK to use
*your own* mutable objects as keys provided that the "value" isn't
based on anything mutable.
Using an NSMutableString or some other mutable object from the
frameworks would be Very Bad, because mutating them will change
their value, but that isn't true for all objects.
Separately, collections use isEqual: on the object values to
determine equality, when they care. (I doubt that NSDictionary
cares about object value equality, but NSSet certainly does, as
does NSArray, when asked to compare objects.)
Separately, collections may (and presumably sometimes do) use
*object* hash values to distribute objects in memory. (Obviously,
NSSet does, and for all we know NSDictionary does too, to
distribute object values that stored under the same key hash value
-- though it would be an implementation detail.)
It's better to think of NSSet as a collection that has only *keys*.
And NSDictionary doesn't hash objects; you can look at the
implementation in CoreFoundation if you want.
So object values must also follow the isEqual:/hash rules.
If you implement -isEqual:, you should implement -hash and make sure
that two objects for which -isEqual: returns YES return the same
hash value.
That, however, is not what we're discussing here; we're currently
discussing the risk associated with mutable objects in collections,
and I stand by my previous post.
So AFAIK your reading of the documentation is absolutely correct.
Object values cannot be mutated while in a collection, unless their
hash value doesn't depend on the mutated properties.
No, not true.
Key values cannot be mutated while used in a collection, period.
Correct.
Excuse my intrusion in this discussion, but I don't really understand
why 'isEqual:' and 'compare:' results must not change when an object
is used as key.
My though was that as long as the hash remain the same, it should not
be an issue. I don't see any case where it may be useful, but don't
see why it would be illegal ?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden