Re: NSNumber is completely broken
Re: NSNumber is completely broken
- Subject: Re: NSNumber is completely broken
- From: Will Mason <email@hidden>
- Date: Wed, 25 May 2005 04:57:05 -0700 (PDT)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
I wouldn't say that NSNumber is totally broken based on the results
that you're seeing. It's just an implementation decision that disagrees
with an implementation decision that you would make. NSNumber still
behaves properly according to all the publicly documented behaviors.
About your problem, if you're bridging Cocoa to another language, then
you should rely on the types that NSNumber claims, according to its
objCType method, to be supporting. If you really must know the type
with which the NSNumber was initialized, then it appears that there's
no way to know that. As I'm sure you know, the usual usage is to
request types that you know that the NSNumber will present correctly to
you. For example, you initialize the NSNumber with a BOOL
(initWithBool:) and thereafter you only request BOOLs from the NSNumber
(boolValue). I think it's a bit unfortunate that they use one class to
represent all intrinsic types. I much prefer Java's way of having a
distinct object type for each intrinsic type, but that's totally
off-topic.
Good luck,
Will
--- Todd Blanchard <email@hidden> wrote:
> I'm working on bridging Cocoa to another language and have found that
>
> NSNumber is totally broken. Does nobody bother to test anything
> anymore?
>
> These are the objective C types recorded for various C types
>
> Bool: c
> Char: i
> Unsigned Char: i
> Short: i
> Unsigned Short: i
> Int: i
> Unsigned Int: i
> Long: i
> Unsigned Long: i
> Float: f
> Double: d
>
> But it should be:
> BOOL: c
> char: c
> unsigned char: C
> short: s
> unsigned short: S
> int: i
> unsigned int: I
> long: l
> unsigned long: L
> float: f
> double: d
> (mini-rant - why bother to have numberWithBool if the value is
> indistinguishable from char once the NSNumber is created?)
>
> I got it using this little program:
>
> id n = nil;
> #define T(type) n=[NSNumber numberWith ## type : 0]; printf("%s:
>
> \t\t\t\t%s\n", #type , [n objCType]);
> #define U(type) n=[NSNumber numberWithUnsigned ## type : 0];
> printf("Unsigned %s:\t%s\n", #type , [n objCType]);
> #define C(type) printf("%s: %s\n", #type ,@encode(type));
>
> T(Bool)
> T(Char)
> U(Char)
> T(Short)
> U(Short)
> T(Int)
> U(Int)
> T(Long)
> U(Long)
> T(Float)
> T(Double)
>
> C(BOOL)
> C(char)
> C(unsigned char)
> C(short)
> C(unsigned short)
> C(int)
> C(unsigned int)
> C(long)
> C(unsigned long)
> C(float)
> C(double)
>
> Suggestions on workarounds? My two initial thoughts are to replace
> all the initialization methods on NSNumber using a category or to
> subclass it and pose. Comments on pros and cons of each would be
> welcome. If I pose, I suppose I could add an extra flag to mark
> whether its a bool or not. What else?
>
> Filed Bug: 4129891
>
> -Todd Blanchard> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden