On Jan 18, 2010, at 4:55 PM, Ken Thomases wrote: > On Jan 18, 2010, at 11:01 AM, Jeffrey Oleander wrote: > >> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Collections/Articles/Sets.html >> >> "Set Fundamentals: Note that if mutable objects are stored in a set, either >> the hash method of the objects shouldn’t depend on the internal state of the >> mutable objects or the mutable objects shouldn’t be modified while they’re >> in the set (note that it can be difficult to know whether or not a given >> object is in a collection)." >> >> So, you can use your own hash function to determine where in the set each >> item is stored. In this case, each item stored in the set is an >> NSMutableDictionary. > > And... you can't change the hash function used by NSMutableDictionary. So, > for a custom class, you can implement a custom -hash method. But for > NSMutableDictionary, you can't. And, if you do implement a custom -hash > method for your custom class which is insensitive to the "contents" (whatever > that might be) of its instances, then that's a _very_ different equality > semantic than NSDictionary provides. > > >> http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Foundation/Classes/NSDictionary_Class/Reference/Reference.html >> >> "Internally, a dictionary uses a hash table to organize its storage and to >> provide rapid access to a value given the corresponding key. However, the >> methods defined in this cluster insulate you from the complexities of >> working with hash tables, hashing functions, or the hashed value of keys. >> The methods described below take keys directly, not their hashed form." >> >> So, you may use your own hash function to create your keys... or not, as you >> wish. > > Um, the keys are not typically the output of a hash function. Well, you can > use such for keys, but that's irrelevant to the hash of the dictionary > object, itself. > >> But then the NSDictionary and NSMutableDictionary will hash the keys you >> pass to their methods using their own, internal, hash function, to determine >> where objects are stored in the dictionary. > > Right. So, if you mutate the dictionary while it's in the set, you will > break things. That's why a set of mutable dictionaries (as opposed to > immutable dictionaries, or some other data structure entirely) raises a huge > red flag. > > As I previously cited, from the documentation of -[NSObject hash]: > http://developer.apple.com/mac/library/documentation/cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html > > "If a mutable object is added to a collection that uses hash values to > determine the object’s position in the collection, the value returned by the > hash method of the object must not change while the object is in the > collection. Therefore, either the hash method must not rely on any of the > object’s internal state information or you must make sure the object’s > internal state information does not change while the object is in the > collection. Thus, for example, a mutable dictionary can be put in a hash > table but you must not change it while it is in there. (Note that it can be > difficult to know whether or not a given object is in a collection.)" > > Note that this case of mutable dictionaries in a collection is explicitly > warned about. > > >> But my primary point was to ask the original poster to think about why he is >> using this arrangement of instances of NSMutableDictionary stored in an >> NSMutableSet. > > Yes, and that was my point, too.
Thanks for the insight guys - you have convinced me to re-think my data model. I never even began to conceive of some of the issues you have put on the table. > > -Ken > _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com