mikeash.com pyblog/friday-qa-2010-05-28-leopard-collection-classes.html comments

mikeash - 2010-06-23 03:50:41

Wed, 23 Jun 2010 03:50:41 GMT

While that answers the question of why they haven't (and probably can't) fix it, it doesn't answer the question of why they built it that way in the first place.

Kyle Sluder - 2010-06-23 03:31:00

Wed, 23 Jun 2010 03:31:00 GMT

I imagine the main reason for making -setObject:forKey: always copy the key irrespective of the options passed to the CF constructor was compatibility with existing code that passed mutable strings as dictionary keys, relying on them being copied. Of course, as you say, the opportunity for making that breaking change has certainly not increased since.

mikeash - 2010-05-29 23:02:45

Sat, 29 May 2010 23:02:45 GMT

Harvey: I haven't bothered. I know what the behavior is now, and don't think it would be worth the time to file a bug.

Mike Abdullah: That's amusing. I don't know how comfortable I'd be relying on this, but on the other hand it probably couldn't be changed without breaking tons of code now.

Mike Abdullah - 2010-05-29 11:54:12

Sat, 29 May 2010 11:54:12 GMT

My understanding is that it is the NSDictionary methods which provide the copying behaviour. Keys are copied then passed on to CoreFoundation to deal with.

This is true regardless of how the dictionary was created. So if you allocate an NSDictionary, but then set keys using CoreFoundation, they will be retained not copied. I have a convenience method (ab)using this:

- (void)setObject:(id)anObject forKey:(id)aKey copyKeyFirst:(BOOL)copyKey;
{
    if (copyKey)
    {
        [self setObject:anObject forKey:aKey];
    }
    else
    {
        CFDictionarySetValue((CFMutableDictionaryRef)self, aKey, anObject);
    }
}

Harvey - 2010-05-29 07:54:45

Sat, 29 May 2010 07:54:45 GMT

Mike: Have you tried filing a bug on the bridging docs?

mikeash - 2010-05-28 18:41:47

Fri, 28 May 2010 18:41:47 GMT

Christopher Lloyd: Stuff with the same name existed, but is so different that I don't consider it to be the same API at all. They were like CF collections but without any of the conveniences they offered. Now they're actually useful.

Charles Parnot: Thanks for pointing out those convenience methods, I missed them because they're in a category. Regarding the radar, I believe the documentation is contradictory here. You're correct that the method is documented as saying the key is copied, but CFDictionary is documented as calling your callback, and the bridging docs don't state who wins.

Charles Parnot - 2010-05-28 18:15:45

Fri, 28 May 2010 18:15:45 GMT

Great overview, thanks very much!

One thing maybe was not explicit in the text about NSPointerArray: it also has the class methods `+pointerArrayWithStrongObjects` and `+ pointerArrayWithWeakObjects`. Just pointing it out in case somebody is intimidated by the NSPointerFunctions stuff.

About #4350677, on the other hand, the documentation for 'setObject:forKey:' says "..The key is copied..", so it seems they just stick to what the docs say ;-)

Christopher Lloyd - 2010-05-28 17:41:37

Fri, 28 May 2010 17:41:37 GMT

NSHashTable and NSMapTable have been around since 10.0 and before, they were just C structs prior to 10.5. I assume the upgrade to a class and the new options were to make them work sanely with the GC. Disappointingly they aren't in iPhoneOS, I find myself using NSMapTable quite a lot.