Re: [NSDecimalNumber numberWithDouble:x]

[David Ayers]

Adam Fedor wrote:
> 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.

I'm pretty sure the implementations in NSNumber must test for the 
*abstract* NSNumber class (and should/could arguably also test the 
concrete class corresponding to the type supplied).

 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...).

I believe this is the result trying to save alloc/dealloc of cached 
values.  Another reason those methods really need to check for NSNumber 
(and applicableConcreteClass) otherwise custom subclasses (or 
NSDecimalNumber:s) will return the cached NS(scaler)Number instances.

Cheers,
David