Re: [NSDecimalNumber numberWithDouble:x]

[Adam Fedor]

On Monday, January 12, 2004, at 07:47 AM, David Ayers wrote:

> Manuel Guesdon wrote:
> > On Mon, 12 Jan 2004 13:05:27 +0100 David Ayers <address@hidden> 
> > wrote:
> >  >| Acutally I agree with Adam.  NSNumber should allow *any* custom  
> > >| subclasses "to do the right thing".  These aren't primiative 
> > methods.  >| So therefor these look like bugs in the NSNumber 
> > implementation to me.  >| I think all these numberWith*: methods 
> > should test:
> >  >| if (self == [NSNumber class] || self == [applicableConcreteClass 
> > class])
> >  >| (or rather the cached versions) before executing their current  
> > >| implementations using the NSAllocateObject function.  Otherwise it 
> >  >| should probaly just call [[self alloc] initWith*:] as you have 
> > done.
> > OK. Should we test against NSNumber class only or also against 
> > NSDoubleNumber, NSShortNumber, ... for cases like:
> > [NSDoubleNumber numberWithDouble:xx] ? As far as I remember, 
> > NSDoubleNumber,... are no more declared as public. So I'm
> > not sure this is a real problem....
>
> Hmm.. we may not really need to test against the concrete classes in 
> the numberWith*: methods as long as we never use them internally and 
> as long as we don't care about code that gets the classes via 
> NSClassFromString and class those methods.  I'd say it's an edge case. 
>  (But I haven't tested what could go wrong.)

I think you only need to test the concrete class. Although there could 
potentially be problems with encoding (encoding/decoding isn't 
implemented in NSDecimalNumber now, but I think it has to be).

Also, NSString works similarly, only it does the object replacement in 
the 'init...' method, which is probably more robust. Perhaps it's too 
much effort to do that with the NSNumber classes, but it might be 
worthwhile since NSNumber now does it in two places (numberWith... and 
initWith...).