Re: [NSDecimalNumber numberWithDouble:x]

[David Ayers]

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

> BTW, as I've got another problem, what is the correct way to test if a NSNumber 
> is a NSDoubleNumber or a NSFloatNumber,...
> before recent changes, we were able to use  isKindOfClass:[NSDoubleNumber 
> class] ? It's interesting to know the kind of
> data and use appropriate methods to keep precision

I think you want NSValue's:
- (const char*) objCType;

Cheers,
David