NSNumber being mapped as string

[rromanchuk]

@interface RestUser : NSObject
@property (atomic, strong) NSNumber *externalId;
@property (atomic, strong) NSString *token;
@property (atomic, strong) NSString *firstName;
@property (atomic, strong) NSString *lastName;
@property (atomic, strong) NSString *email;
@property (atomic, strong) NSArray *checkins;

+ (NSDictionary *)mapping;
@end

@implementation RestUser

@synthesize firstName; 
@synthesize lastName;
@synthesize email;
@synthesize token;
@synthesize checkins;
@synthesize externalId;

+ (NSDictionary *)mapping {
    return [NSDictionary dictionaryWithObjectsAndKeys:
    @"firstName", @"firstname",
    @"lastName", @"lastname",
    @"email", @"email",
    @"externalId", @"id",
    nil];
}

RestUser *user = [RestUser objectFromJSONObject:JSON mapping:[RestUser mapping]];
NSLog(@"CLASS: %@", NSStringFromClass([user.externalId class]));

results in

CLASS: __NSCFString

[rromanchuk]

how is this even possible? o_O

[jamztang]

Maybe your json response the id as a string but not a number.

[rromanchuk]

good point, and you already have this covered with tests.. I will investigate and close this. But how does the compiler even allow a different datatype? I guess casting into a

[jamztang]

I guess it isn't the compiler fault. The values are assigned to the property in runtime, iOS decide not to crash the app even when the target class doesn't match. Maybe someone can answer this better than me.

[laveur]

This is to be expected, Objective-C is a loosely typed Programming Language. everything really are opaque pointers to a struct under the hood. And because everything is usually inherited from NSObject you can easily set a string for a number. Especially when you are using KVC. Hopefully this hopes...

[rromanchuk]

makes sense, took me a bit to figure out why core data was crashing. I need to just pay a little more attention and be a little more defensive.