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.