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 protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
