Subclassing NSNumber

Question

I want to add a property to an NSNumber class, so I have to subclass it. The documentation states that I then have to override all NSValue primitive methods. Since the NSValue documentation does not state which methods are the primitive ones, I figured that these two are probably the primitive ones for instantiation:

– initWithBytes:objCType:  
+ valueWithBytes:objCType:

So I made my class as:

@interface MultipleNumber : NSNumber {  
    NSNumber *_number;  
}  
@property (nonatomic, getter = isMultiple) BOOL multiple;  
@end

@implementation MultipleNumber  
@synthesize multiple=_multiple;  

-(id)initWithBytes:(const void *)value objCType:(const char *)type {  
    self = [super init];  
    if (self) {
        _number=[[NSNumber alloc] initWithBytes:value objCType:type];
    }
    return self;
}

+(NSValue *)valueWithBytes:(const void *)value objCType:(const char *)type {
   return [[[MultipleNumber alloc] initWithBytes:value objCType:type] autorelease];
}

-(void)getValue:(void *)value { [_number getValue:value]; }

-(const char *)objCType { return [_number objCType]; }

@end

But when I call[NSNumber numberWithBool:YES], I still get a _NSCFBoolean class back and the "primitive methods" are not called. How can I figure out what methods are considered primitive?

Answer 1

You don't need to subclass NSNumber in order to add a property. You can add a property more easily using an associative reference. Subclassing NSNumber is quite tricky because it's a class cluster.

---

EDIT: @Remco makes an important point down in his comments to @diablosnuevos that I wanted to call out in an answer:

Yes, I finally did make a subclass by trial and error, because the NSNumbers returned are shared instances, so storing a associated reference is also shared. – Remco Poelstra May 16 at 9:09

This is a really important thing to remember. NSNumber caches the integers from -1 to 12 and treats them as singletons. In OSX 10.7, NSNumber is implemented as a tagged pointer (haven't dug into the implications for associated references there). The point is that while associated references are quite useful, there can be underlying implementation details that will burn you.

The deeper lesson here is that subclassing or augmenting NSNumber probably isn't a good idea in any case. NSNumber is a very low-level object. It's almost certainly better to build another class that owns an NSNumber, much like NSAttributedString owns an NSString rather than extending NSString.

I don't know the specifics of the problem being solved here, but the problems encountered make for an interesting lesson.

Answer 2

I find most answers above unacceptable. Many times, subclassing may be the best design choice. The reason you are getting _NSCFBoolean is because that's what the convenience method numberWithBool: is designed to do -- it conveniently gives you an NSNumber with the correct private subclass. You should write your own convenience method aka + (NSNumber*)numberWithMultiple...

Answer 3

EDIT: Heed the warnings in comments! This is a good solution for many classes; it may not be good for NSNumber, NSString, and possibly others like NSArray etc. because they do behind-the-scenes magic for performance reasons that may lead to unexpected behavior, like sharing instances.

How about saving yourself the pain of subclassing, and instead extending the class with a category?

Have a look here: http://oleb.net/blog/2011/05/faking-ivars-in-objc-categories-with-associative-references/