Lists

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Re: NSNumber is completely broken

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSNumber is completely broken

Subject: Re: NSNumber is completely broken
From: Bob Ippolito <email@hidden>
Date: Wed, 25 May 2005 16:40:10 -0700

PyObjC has a hybrid approach, it wraps NSNumber as a Python subclass of the "register type", so it acts like a Python number but also carries around the NSNumber's identity as well as the methods that you can use to get whatever you want.

NSNumber is really closer to Perl's scalar, which is "whatever you use it as", rather than some specific type.

>>> from Foundation import *
>>> import sys
>>> big = NSNumber.numberWithUnsignedInt_(sys.maxint + 1)
>>> big
-2147483648
>>> type(big)
<class 'objc._pythonify.OC_PythonInt'>
>>> type(big).__bases__
(<type 'int'>,)
>>> big.unsignedIntValue()
2147483648L
>>> type(_)
<type 'long'>

It's certainly not broken, for the reasons that Will states, ESPECIALLY because it can't do any math whatsoever. You must ask for some specific type before you can operate on it. Imagine the documentation Apple would have to write and all the arbitrary decisions that would need to be made (which would certainly be discussed ad nauseam here) if it could do operations ;)

For human representation, it would certainly be nice if it cared about whether the intrinsic value should be displayed signed or unsigned, but it's certainly no requirement for the machine to deal with everything correctly.

Replacing all of the initialization methods of NSNumber would be for naught because it's toll-free bridged to CoreFoundation (where it's *really* implemented), unless you want to runtime patch those functions too.. and even then, you still have to deal with the "ambiguously" typed stuff that would come out of serializations, etc.

-bob

On May 25, 2005, at 4:57 AM, Will Mason wrote:

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:

40yahoo.com


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


_______________________________________________
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



References:  
  >Re: NSNumber is completely broken (From: Will Mason <email@hidden>)




Prev by Date:
Re: Grouping undo-able actions with CoreData [SOLVED!]

Next by Date:
Re: Function calling

Previous by thread:
Re: NSNumber is completely broken

Next by thread:
Re: NSNumber is completely broken

Index(es):

Date
Thread