On Feb 22, 2014, at 6:58 AM, jonat...@mugginsoft.com wrote: > Now I don’t care know how NSNumber persists its value nor with what type it > was initialised. What I do care about in this case is what -objCType returns. > If I create a NSNumber like so: > > NSNumber *n = @((int)5); > > Then [n objCType] returns “i”.
For the particular version of the framework you tested and with the particular value 5. There's no guarantee that it will return that for any other version of the framework or all integer values. In fact, since NSNumber can definitely support integer values that exceed the capacity of an int, it certain that for some integer values it won't return "i". In fact, there may be ways of constructing an NSNumber whose value is 5 but which has a different -objCType, even in the same version of the framework. > From this I conclude that the canonical/reported representation is an int and > I proceed accordingly. "Reported", yes; "canonical", no. > And that’s all that I require. Except what if it's different? > The Mono method declares I need a pointer to an int. > If my Obj-C argument id object says, yes, I have a canonical/reported int and > provide a pointer to such, then we are good to go. > > I can define a complex number class. > MYComplexNumber * cn = [MYComplexNumber complexNumberWithString:@“5,2"]; > This can return “i” for -objCType and that’s okay. Huh? I don't follow. I'm not sure why you're discussing a hypothetical class implementing -objCType. It's not like that's a normal feature of classes. I also don't understand how you expect a complex number to have a type which consists of a single integer. > Now if I initialise it with @“5.5,2” -objCType may respond with “f”. NSNumber is quite likely to return "f", too. > Now that is not okay. I have a unexpected type but this is something that I > can detect and handle, likely by raising an exception. I hope you're OK with that happening quite often. >> Keep in mind that NSDecimalNumber is-a NSNumber > > Your point about NSNumber subclasses such as NSDecimaNumber is well made and > a case in point. > It turns out that NSDecimaNumber returns “d” for double. NSDecimalNumber can represent values that are outside of the range of doubles. So, _some_ NSDecimalNumber instances _may_ return "d" for double, but others definitely won't. Just to be clear, NSDecimalNumber is not the class uses to represent floating-point values, necessarily. It's for representing numbers with very many significant digits and a large range of exponents. Good old NSNumber is perfectly capable of representing float and double values, itself. > My category will produce a pointer to a double representation of the > NSDecimaNumber. > And that’s okay. > NSDecimaNumber instances can safely(!!) be used as arguments to Mono methods > that take a double parameter. Um, no. Your whole approach is flawed because you believe that NSNumber is advertising a stable and reliable representation. It isn't. As ever, implementation details are private and subject to change. Every instance of NSNumber is entitled to use a different representation. Two NSNumbers which compare equal may not have the same representation. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
