Re: Danger: @true and @false aren't considered booleans
Re: Danger: @true and @false aren't considered booleans
- Subject: Re: Danger: @true and @false aren't considered booleans
- From: Jens Alfke <email@hidden>
- Date: Sun, 19 Aug 2012 14:59:26 -0700
On Aug 19, 2012, at 2:23 AM, Andreas Grosam < email@hidden> wrote: In case of JSON, if a JSON Boolean will be represented as a NSNumber, transforming a NSNumber which has been created as bool is only not ambiguous because there is no representation for a "JSON char". That is, if the underlaying type is a char, the JSON encoder *have to* assume that it is a BOOL.
That's not true. Type 'char' is simply an 8-bit signed integer, and JSON certainly represents those! [NSNumber numberWithChar: 5] serializes to JSON as "5". And in fact [NSNumber numberWithChar: 1] serializes to JSON as "1", not "true". Note: it's not sufficient to check whether a NSNumber instance is a boolean by comparing the *pointer* against kCFBooleanTrue respectively kCFBooleanFalse.
Nevertheless, this appears to be what JSNSONSerialization does: [NSNumber numberWithChar: 1] —> "1" [NSNumber numberWithBOOL: YES] —> "true" even though there is no difference I can tell between the two NSNumber instances (both have encoding "c" and value 1.)
Comparing the pointers may fail for example when that boolean value is a property of a CoreData managed object. Really? As far as I can tell, +numberWithBool: _always_ returns kCFBooleanTrue or kCFBooleanFalse. There doesn't seem to be a way to generate other boolean NSNumber instances.
—Jens |
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden