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: Alastair Houghton <email@hidden>
- Date: Fri, 21 Aug 2009 10:31:52 +0100
On 21 Aug 2009, at 10:07, Jean-Daniel Dupas wrote:
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 ?
In the current implementation, I think you're probably right that -
isEqual: and -compare: could change their results as long as -hash
stayed the same.
The key words are "current implementation". For instance, Apple might
decide in future to change NSDictionary and/or NSSet such that there
is an implementation that uses a balanced tree rather than a hash
table. I'm not saying that they will, and obviously if they did
they'd need to make -compare: compulsory for the keys in such a thing
(which in practice probably means they'd want to use a new subclass of
NSDictionary/NSSet, and in Core Foundation add new creation APIs), and
the structure would depend on the comparison results rather than the
hash values.
Also, I think it's a mistake to confine oneself to thinking solely
about the provided collection classes. There are certainly uses for
ordered associative collections, and the most likely implementations
would rely critically on the behaviour of -compare:.
So on that particular point, I agree with Quincy :-)
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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