Re: Objects as keys NSMutableDictionary
Re: Objects as keys NSMutableDictionary
- Subject: Re: Objects as keys NSMutableDictionary
- From: email@hidden
- Date: Mon, 10 Jul 2006 00:49:24 +1000
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 Reference Library/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@hidden
iChat & email: email@hidden
Jabber: email@hidden
Google Talk: email@hidden
http://homepage.mac.com/wadetregaskis/
-- Sed quis custodiet ipsos custodes?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden