Hi, I'm Adam. Email me about: CTOs, Mobile/iOS, Project Management, and Development

2 reasons to beware Apple’s NSDictionary, and CoreData

Ever seen this hard to notice bug in an iPhone / Mac project? Caused by a flaw (bug?) in Apple’s own API:

NSDictionary * map;

NSObject * key;
NSObject * value;

// NB: next line will frequently crash at runtime
// …but even if doesn’t crash, it probably won’t do
// what you’d expect it to:
[map setObject:value forKey:key];

if( value != [map objectForKey:key] ) // HA!
{
NSAssert( 1 == 0, @”What the **** just happened??” );
}

NSDictionary is one of the nastier things I’ve seen in a programming language: in an Object-Oriented Language, it’s a class that refuses to take Objects as arguments, *but pretends to*. If you attempt it, it either crashes, or it invalidates your objects, breaking contracts all over the place.

ObjC’s bizarre design

In the days pre-OOP, a “dictionary” was something that mapped:

“a string”
to
“anything” (usually: basic datatypes – e.g. strings, integers, floats, etc).

In the days of OOP, the same thing is usually called a “map” (which is a better term) – although the terms are synonymous – and maps:

“an object”
to
“another object”

What did Apple/NextStep/Crazy-Guys-Behind ObjC do?

NSDictionary: maps:

“STRINGS ONLY” (no objects allowed!)
to
“OBJECTS ONLY” (no core datatypes allowed!)

But … I can use an NSObject as key?

Yep – but Apple’s internal implementation takes a *copy* of the object, and uses that as a key – rather than using the object that you gave it. This is a common problem in OOP languages and implementations of Map – e.g. Java does the same thing.

Unfortunately, this means that you can call “setObject:forKey:”, and then “objectForKey:” will return nil *for the same key*.

In Java and other OOP languages, you are required to implement a custom “isObjectEqualToObject” method. In ObjC too – except that that method is ILLEGAL if you’re using CoreData.

And ObjC will crash too, as a bonus

I’ve never seen this in other OOP languages, but in ObjC *additionally*: if you don’t manually add to the object you pass-in … it crashes at runtime. Yay!

How come? AFAICT, Apple’s header file is wrong:

– (void)setObject:(id)anObject forKey:(id)aKey // You lie!

it seems the implementation of that method is:

– (void)setObject:(id)anObject forKey:(id<NSCopying>)aKey; // the correct signature?

Net result? Code that happily compiles … will crash. ARGH!

Two reasons to beware…

…so what’s the other one?

Ah, just the one we see again and again on live projects, wasting hours and hours of time:

NSDictionary* dictionary = [NSDictionary dictionaryWithObjectsAndKeys:
object1, key1,
object2, key2,
nil];

NSLog( @”dictionary = %@”, dictionary ); // but it only has one key/value pair. ?!?!?

Ah, well … that nil … what happens when object2 is nil? Oh, damn.

What about if key2 is nil? Now we’re really nasty … we’ve given it “half” of key/value pair. Nice!

5 thoughts on “2 reasons to beware Apple’s NSDictionary, and CoreData”

Comments are closed.