Re: copy & isEqual nightmares
Re: copy & isEqual nightmares
- Subject: Re: copy & isEqual nightmares
- From: Uli Kusterer <email@hidden>
- Date: Wed, 15 Feb 2012 09:50:07 +0100
On 14.02.2012, at 17:35, Quincey Morris wrote:
> Yes, you're right, I rashly forgot to consider all the possibilities. There is a kind of class whose instances are *not* (necessarily) isEqual to themselves over time. I don't know that there's terminology for this -- "mutable object" doesn't cover it, because (say) NSMutableDictionary is mutable but *is* isEqual to itself over time.
Why would there ever be an object that is not -isEqual: to itself? Now you've lost me.
> NSDictionary may not use the value object hashes, but I don't see that there's anything from preventing it from doing so if it proved beneficial to the implementation (as well as, of course, using the hashes of the key objects). But there's also NSSet, NSCountedSet and NSOrderedSet, where the [un-copied] object *is* the key, as well as things like NSMapTable.
Those are good examples of where you may get in trouble modifying an object, and definitely better than my hypothetical example.
> And there's nothing preventing NSArray from keeping a supplementary hash-based index to assist in looking up objects, although I can't imagine it's ever likely to be implemented that way.
I think Apple is too pragmatic to make such a change now to classes like NSArray or NSDictionary. Even despite documentation, I'm pretty sure too many applications would break after such a change.
> What you say makes practical sense, and represents sane expectations. However, again, I think it's important to keep track of what the API contract is, and the API contract doesn't go that far.
That's a good maxim to live by, but still doesn't change that computer science has a strict definition for what a hash is (a unidirectional projection, or whatever it is called in English), and it also requires that it "can be used as a table address in a hash table structure", which implicitly restricts the choice of implementation somewhat.
This is not just my interpretation. A one-way projection that turns a given set of (object) values into a smaller set of numeric values and its behaviour is defined by set theory, and works exactly as said: Identical values end up projected onto the same value, and some collisions occur due to the limited value space. Hash not equal -> objects not equal. Hash equal -> object equal or hash collision; compare in detail.
The only other option would be to have a call to rand() or time() in there to mix things up, but then it would not be suitable for use in a hash table structure. The definitions may be terse, but they work together to provide exactly this result.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
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