On 19/07/2012, at 9:46 AM, William Squires wrote: > Okay, but the problem with wrapped scalars is determining what went in (int, > float, char, BOOL) once you get it out (presumably as an NSNumber)? I suppose > one way would be to define a 'type' dictionary in the object whose properties > I'm interested in, but this would create extra complexity when creating the > low-level model objects.
In fact you can't find this out for certain, the documentation states: "Note that number objects do not necessarily preserve the type they are created with". The internal storage is enough to preserve the precision of the value it was created with, but no more. When you ask for its value, the precision of the result is at least as good as what it was created with, and that's all it guarantees. Note that NSNumber has a -stringValue method, and NSString has -intValue and -floatValue methods too. So interconverting between numeric values and strings further exempts you from knowing the object type. However, I'm not sure whether, if you pass a string to -setValue:forKey: and the property is numeric, whether a conversion to an NSNumber is done there, or whether the object would just store the string. That might cause problems. Typically for UI controls, any conversion of this kind is done by the control (or strictly, by its formatter), so the situation doesn't tend to arise. > What I want is a way - in my parser - to check if the property at <keypath> > is of a compatible data type to the <value> before executing the 'codon' and, > if it's not, to raise an NSException with a descriptive message (including > the name of the effect, and the mis-written 'codon'). Why not just declare the property to always be a numeric type, and always convert it to one if necessary? Because it's trivial to get it in string form, you don't need to deal with strings here. Or, if there are other properties that have to be strings (e.g. player name, which has no numeric representation), you could wrap the whole thing in an object of your own class that preserves type information, so you know what the property ultimately needs to be converted to. Then your properties deal in this object type rather than NSNumbers or NSStrings, and you have a generic solution. Your parser could look at the value and determine that in fact it has no numeric representation, and so it knows it must preserve its "stringyness", and not return it as a NSNumber. --Graham _______________________________________________ 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
