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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
