[wataru]

Is there a way to explicitly typecast NSStrings @"YES" or @"NO" as booleans? I've run into some inconsistencies with testing such objects (they have to be NSStrings not BOOLs because they need to be stored in an NSDictionary).

[Chuckit]

NSNumber would be more appropriate for this. It's meant for storing scalars in object containers like NSDictionary.

[wataru]

Oops, thanks. Didn't think of NSNumber.

[larkost]

Don't use NSNumber for this... Apple has implemented a system in the compiler that caches some forms of NSNumber so that there is only one instance. This is a great win for speed, but can have some unexpected consequences if you are using it like you are proposing to use it.

The best solution is to create a quick class that inherits from NSObject and has a single member variable (a BOOL) and a getter and a setter (the latter only if you need to change it). You can even make factory methods to produce one with FALSE and one with TRUE.

[Chuckit]

Really? I've used NSNumber for this kind of thing before. Do you have any links that explain exactly what Apple's done? I'm pretty curious.

[wataru]

I implemented it with NSNumber and haven't experienced any problems so far. I'd also like to know more about the problems you mentioned.

[larkost]

NSOrdinal numbers up to 12 (I think...) now all get represented by a single instance of NSNumber (since it is immutable anyways). I have had several people who were admittedly doing odd things run across problems because they were dealing with each reference to it as a reference to a private object (things like comparing the pointers, or working with the memory allocation closely).

But ultimately, you would be better off with your own class because it would be lighter weight than the NSNumber meta-class. It is a shame that there is not an Obj-C BOOL wrapper...

[smeger]

You could always use (id)kCFBooleanTrue and (id)kCFBooleanFalse.

When comparing any NSObjects, you shouldn't do pointer-based equality testing unless you're absolutely SURE that they'll be the same pointers, which is rare. So instead of using ==, you should be using isEqual: or, if you know the classes, one of the optimized versions like isEqualToString:.

Pointer-based stuff rarely works because a lot of times, Cocoa will copy an object transparently. Like, if you use an NSString as a key in an NSDictionary, Cocoa actually uses a copy of the NSString. So if you try to use pointer-equality testing on the key later, the result'll always be false. This stuff is documented, but it's easy to miss.

[Wevah]

Originally Posted by larkost

It is a shame that there is not an Obj-C BOOL wrapper...

I'm pretty sure this is what +[NSNumber numberWithBool:], etc., are for.

(Also, what smeger said.)