Ever seen this hard to notice bug in an iPhone \/ Mac project? Caused by a flaw (bug?) in Apple’s own API:<\/p>\n
\nNSDictionary * map;
\n…
\nNSObject * key;
\nNSObject * value;
\n…
\n\/\/ NB: next line will frequently crash at runtime
\n\/\/ …but even if doesn’t crash, it probably won’t do
\n\/\/ what you’d expect it to:
\n[map setObject:value forKey:key];<\/p>\nif( value != [map objectForKey:key] ) \/\/ HA!
\n{
\n NSAssert( 1 == 0, @”What the **** just happened??” );
\n}\n<\/p><\/blockquote>\nNSDictionary 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.<\/p>\n
ObjC’s bizarre design<\/h4>\n
In the days pre-OOP, a “dictionary” was something that mapped:<\/p>\n
\n “a string”
\nto
\n“anything” (usually: basic datatypes – e.g. strings, integers, floats, etc).\n<\/p><\/blockquote>\nIn the days of OOP, the same thing is usually called a “map” (which is a better term) – although the terms are synonymous – and maps:<\/p>\n
\n“an object”
\nto
\n“another object”\n<\/p><\/blockquote>\nWhat did Apple\/NextStep\/Crazy-Guys-Behind ObjC do?<\/p>\n
NSDictionary: maps:<\/p>\n
\n“STRINGS ONLY” (no objects allowed!)
\nto
\n“OBJECTS ONLY” (no core datatypes allowed!)\n<\/p><\/blockquote>\nBut … I can use an NSObject as key?<\/h4>\n
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.<\/p>\n
Unfortunately, this means that you can call “setObject:forKey:”, and then “objectForKey:” will return nil *for the same key*.<\/p>\n
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.<\/p>\n
And ObjC will crash too, as a bonus<\/h4>\n
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!<\/p>\n How come? AFAICT, Apple’s header file is wrong:<\/p>\n
\n– (void)setObject:(id)anObject forKey:(id)aKey \/\/ You lie!\n<\/p><\/blockquote>\n
it seems the implementation of that method is:<\/p>\n
\n– (void)setObject:(id)anObject forKey:(id<NSCopying>)aKey; \/\/ the correct signature?\n<\/p><\/blockquote>\n
Net result? Code that happily compiles … will crash. ARGH!<\/p>\n
Two reasons to beware… <\/h3>\n
…so what’s the other one?<\/p>\n
Ah, just the one we see again and again on live projects, wasting hours and hours of time:<\/p>\n
\nNSDictionary* dictionary = [NSDictionary dictionaryWithObjectsAndKeys:
\n object1, key1,
\n object2, key2,
\n nil];<\/p>\nNSLog( @”dictionary = %@”, dictionary ); \/\/ but it only has one key\/value pair. ?!?!?\n<\/p><\/blockquote>\n
Ah, well … that nil … what happens when object2 is nil? Oh, damn.<\/p>\n
What about if key2 is nil? Now we’re really nasty … we’ve given it “half” of key\/value pair. Nice!<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,20],"tags":[],"_links":{"self":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/1826"}],"collection":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/comments?post=1826"}],"version-history":[{"count":0,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/1826\/revisions"}],"wp:attachment":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/media?parent=1826"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/categories?post=1826"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/tags?post=1826"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}