mikeash.com pyblog/friday-qa-2010-05-28-leopard-collection-classes.html commentshttp://www.mikeash.com/?page=pyblog/friday-qa-2010-05-28-leopard-collection-classes.html#commentsmikeash.com Recent CommentsTue, 19 Mar 2024 08:19:19 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssmikeash - 2010-06-23 03:50:41http://www.mikeash.com/?page=pyblog/friday-qa-2010-05-28-leopard-collection-classes.html#commentsWhile 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.92a100f815e2ddaa24a5b34583da1b38Wed, 23 Jun 2010 03:50:41 GMTKyle Sluder - 2010-06-23 03:31:00http://www.mikeash.com/?page=pyblog/friday-qa-2010-05-28-leopard-collection-classes.html#commentsI 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.5f89e5ddc7a0539eef886c3c89a21462Wed, 23 Jun 2010 03:31:00 GMTmikeash - 2010-05-29 23:02:45http://www.mikeash.com/?page=pyblog/friday-qa-2010-05-28-leopard-collection-classes.html#comments<b>Harvey:</b> 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. <br /> <br /><b>Mike Abdullah:</b> 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.a8f08d31571ad8669b67fa7801bfea14Sat, 29 May 2010 23:02:45 GMTMike Abdullah - 2010-05-29 11:54:12http://www.mikeash.com/?page=pyblog/friday-qa-2010-05-28-leopard-collection-classes.html#commentsMy understanding is that it is the NSDictionary methods which provide the copying behaviour. Keys are copied then passed on to CoreFoundation to deal with. <br /> <br />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: <br /> <br />- (void)setObject:(id)anObject forKey:(id)aKey copyKeyFirst:(BOOL)copyKey; <br />{ <br />&nbsp;&nbsp;&nbsp;&nbsp;if (copyKey) <br />&nbsp;&nbsp;&nbsp;&nbsp;{ <br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[self setObject:anObject forKey:aKey]; <br />&nbsp;&nbsp;&nbsp;&nbsp;} <br />&nbsp;&nbsp;&nbsp;&nbsp;else <br />&nbsp;&nbsp;&nbsp;&nbsp;{ <br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CFDictionarySetValue((CFMutableDictionaryRef)self, aKey, anObject); <br />&nbsp;&nbsp;&nbsp;&nbsp;} <br />}fbc8a0b91f1b001bc8cad5b0eeefb349Sat, 29 May 2010 11:54:12 GMTHarvey - 2010-05-29 07:54:45http://www.mikeash.com/?page=pyblog/friday-qa-2010-05-28-leopard-collection-classes.html#commentsMike: Have you tried filing a bug on the bridging docs?cd23cc700985c81862bdf96d802d289eSat, 29 May 2010 07:54:45 GMTmikeash - 2010-05-28 18:41:47http://www.mikeash.com/?page=pyblog/friday-qa-2010-05-28-leopard-collection-classes.html#comments<b>Christopher Lloyd:</b> 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. <br /> <br /><b>Charles Parnot:</b> 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.01da1de5038159312c63ef3fcc785316Fri, 28 May 2010 18:41:47 GMTCharles Parnot - 2010-05-28 18:15:45http://www.mikeash.com/?page=pyblog/friday-qa-2010-05-28-leopard-collection-classes.html#commentsGreat overview, thanks very much! <br /> <br />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. <br /> <br />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 ;-) <br />64957ca86f643983b981096f362e2c2fFri, 28 May 2010 18:15:45 GMTChristopher Lloyd - 2010-05-28 17:41:37http://www.mikeash.com/?page=pyblog/friday-qa-2010-05-28-leopard-collection-classes.html#commentsNSHashTable 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. 64716d0732abda91ba25268a09b43970Fri, 28 May 2010 17:41:37 GMT