Re: Objects as keys NSMutableDictionary
Re: Objects as keys NSMutableDictionary
- Subject: Re: Objects as keys NSMutableDictionary
- From: Adam Maxwell <email@hidden>
- Date: Mon, 10 Jul 2006 09:05:30 -0700
On Monday, July 10, 2006, at 07:19AM, Rosyna <email@hidden> wrote:
>Well, if it assumed the keys were always strings, then it would just
>use kCFCopyStringDictionaryKeyCallBacks when creating the internal
>CFDictionary. In which case this would make the copyWithZone: a
>useless extra step. It's also why I mistakenly assumed that creating
>the NSDictionary with the CF call using different callbacks would
>address this issue.
It's an inconsistent situation (at least in my view), since the dictionary /will/ use any custom retain/release/equal/hash callbacks you define (so using objectForKey: works fine, and uses pointer equality), but setObject:forKey: will first create a copy...and the copy is then retained using your custom retain callback.
Of course, if you use the CF functions, only the callbacks are used, so it's easy to make a KVC-compliant wrapper for it. I used it to make an NSCountedSet subclass that uses case-insensitive string comparison and stores integers directly in the dictionary; very handy.
>Well, at least the documentation for setObject:forKey: explicitly
>says that the key must respond to copyWithZone:. In these cases, it
>might just be best to return [self retain] or something.
I knew someone would point that out :). It would be nice to know if this callback situation is expected behavior for toll-free bridged classes, though, since I don't want to make assumptions based on current implementation (will my callbacks always work when getting values?).
-- Adam
>
>Ack, at 7/10/06, Adam R. Maxwell said:
>
>>On Jul 10, 2006, at 06:43, Rosyna wrote:
>>
>>>As, I see. NSCFDictionary explicitly calls copyWithZone: before
>>>setting the key using CFDictionarySetValue(). I wonder why.
>>
>>Yes, and that wasn't expected behavior in my case; perhaps it does
>>this because Keys Are Always NSStrings? My bug report disappeared
>>into the black hole of "Duplicate" so I'll never know, but I'm glad
>>Mike Ash pointed this out a few weeks ago.
>
>--
>
>
>Sincerely,
>Rosyna Keller
>Technical Support/Holy Knight/Always needs a hug
>
>Unsanity: Unsane Tools for Insanely Great People
>
>It's either this, or imagining Phil Schiller in a thong.
>
>
_______________________________________________
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