Re: Objects as keys NSMutableDictionary

FROM : wadeslists
DATE : Sun Jul 09 16:49:24 2006

> Technically, NSDictionary and NSSet only require that the 
> comparison and hash behavior of the objects being used as keys be 
> followed.


From file:///Developer/ADC%20Reference%20Library/documentation/Cocoa/
Conceptual/Collections/Concepts/Dictionaries.html#//apple_ref/doc/uid/
20000134 :

"Methods that add entries to dictionaries—whether as part of 
initialization (for all dictionaries) or during modification (for 
mutable dictionaries)— don’t add each value object to the dictionary 
directly, but copy each key argument and add the copy to the 
dictionary. In Objective-C, the dictionary copies each key argument 
(keys must conform to the NSCopying protocol) and adds the copies to 
the dictionary. Each corresponding value object receives a retain 
message to ensure that it won’t be deallocated before the dictionary 
is through with it."

i.e. your keys need to support NSCopying.  The original poster, 
Matthias, more or less knew this.  NSDictionary doesn't require keys 
to be immutable as such, just that they don't mutate while in the 
dictionary - that would obviously pose problems with any internal 
mechanisms it uses like hash tables and the like.  If your object is 
in fact immutable, you can implement your copy methods to just return 
[self retain].  But as Adam noted, this can potentially have unwanted 
side effects (although I myself wouldn't think them likely to crop up 
for 99% of cases).

What offends Matthias is the idea of copying a unique item, like a 
Student instance, where he in a nutshell wants to maintain pointer 
equality, disregarding isEqual: and such things.  There are various 
respectable reasons for doing this; I'm sure Matthias has his.  I've 
had to deal with this issue myself a few times in past.  Assuming you 
don't want to implement NSCopying as [self retain], there are many 
other options..

As James noted, one solution is to use a proxy object which can be 
copied, who's hash value could, for example, be the address of the 
proxied Student instance.

Another alternative is to just use the CF collections directly with 
custom functions for the retain/release/hash/compare/whatever stuff. 
That's more efficient, and probably the better solution - you then 
don't have to worry about things like all those extra proxies 
retaining your Student instances and whatnot.  Less memory usage as 
well, and so forth.

But perhaps the most straightforward way is to just use a different 
key.  For example, it's pretty typical for students to have a unique 
numerical value associated with them.  You could use this as the key 
in all relevant dictionaries, instead of the Student instance itself, 
as NSNumbers can happily be copied and so forth without any worries. 
You'd need an extra dictionary somewhere to map these NSNumbers to 
their proper Student instances (or some other such lookup method), 
but that's probably not a big deal.  And if you're ever interfacing 
with databases, even something like CoreData, using a primitive type 
like a number is probably very handy anyway.

I wouldn't be surprised to find Student implemented the hash method 
to simply return the student ID number anyway.

Wade Tregaskis

    ICQ: 40056898
    AIM, Yahoo & Skype: wadetregaskis
    MSN: <email_removed>
    iChat & email: <email_removed>
    Jabber: <email_removed>
    Google Talk: <email_removed>

    http://homepage.mac.com/wadetregaskis/

-- Sed quis custodiet ipsos custodes?