On Jan 6, 2011, at 12:10, Jon Sigman wrote: > I'm a bit new to Cocoa, and I'm trying to get my head around NSDictionary. In > the Apple documentation it says, "Each entry consists of one object that > represents the key and a second object that is the key's value. ... In > general, > a key can be any object, but note that when using key-value coding the key > must > be a string." > > So, I supply an object that *represents* the key, meaning that this object > itself is not the key, but it's value is? That makes sense for NSStrings, but > not if the key is some other object without an obvious "value", like an > NSArray. > Are the two key types somehow treated differently?
The documentation states (can't give you a link right now, as developer.apple.com seems to be offline for an update) that keys are compared using 'isEqual:'. By default (in the NSObject implementation) that means object pointer equality, but for many classes (including NSString, NSNumber, NSSet and most other collections) it's overridden to be some kind of class-specific "value equality". The semantics of keys also requires them to be immutable (well, maybe that's the semantics of 'isEqual:') and they need to conform to the NSCopying protocol. In practical terms, this means that you're not going to be using arbitrary objects as keys. OTOH, you can use NSValue objects wrapping arbitrary object *pointers* as keys, which is sometimes one way around the semantic restrictions. _______________________________________________ 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
