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

Reply via email to