Re: copy & isEqual nightmares
Re: copy & isEqual nightmares
- Subject: Re: copy & isEqual nightmares
- From: Quincey Morris <email@hidden>
- Date: Tue, 14 Feb 2012 08:35:19 -0800
On Feb 14, 2012, at 04:32 , James Montgomerie wrote:
> Take a mutable string as the canonical example - obviously its hash should change when its contents changes (and it should no longer be isEqual: with a copy of its older self). It's up to the user of the string to ensure that they don't mutate it while it's being used in a collection (i.e. as a key) to ensure predictable program behaviour.
On Feb 14, 2012, at 05:30 , Uli Kusterer wrote:
> Not at all. In fact, it is what NSMutableString does.
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.
On Feb 14, 2012, at 05:30 , Uli Kusterer wrote:
> Keep in mind, this restriction is with regard to NSDictionary. NSDictionary probably uses the hash as the key under which it will store its contents in a tree structure of sorts. If you change an object's hash, the tree would be invalid, and would need to be re-built. However, this applies only to the *keys* of an NSDictionary. The values do not decide the order of the objects in a dictionary, so as long as you only modify the values, you're safe.
>
> That's the reason why NSDictionary copies its keys. If you give it an NSMutableString as the key and then change it, the dictionary would go invalid. By copying the key, it gets turned into an immutable NSString and can't be changed by anyone.
>
> The aforementioned restriction is only an issue for a class like a (fictional) NSSortedArray, which would sort its contents by their values, and if it used a tree or similar structure, that tree would become invalid when an object in it is modified in a way that changes its hash.
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. 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.
My point is that the API contract in the 'hash' documentation *is* the contract, and it just says "objects in collections". None of us gets to make stipulations as to which kinds of collections or what mechanisms their implementations may use.
On Feb 14, 2012, at 05:30 , Uli Kusterer wrote:
> Then the hashes wouldn't work for collection classes. […] I think your confusion comes from the issue that each object defines its own equality semantics. In simpler words, what properties make sense to compare and which don't. […] Now given, most such objects wouldn't implement -copy, but I don't think I've ever seen an object where it made sense to both *not* have copies be equal and support the -copy method.
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.
_______________________________________________
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