Re: KVG generic enough?
Re: KVG generic enough?
- Subject: Re: KVG generic enough?
- From: William Squires <email@hidden>
- Date: Wed, 18 Jul 2012 18:46:59 -0500
On Jul 18, 2012, at 8:16 AM, Marco Tabini wrote:
>
> On 2012-07-18, at 9:08 AM, William Squires <email@hidden> wrote:
>
>> Okay, after reading some of the documentation on KVC coding, I understand (I think) that the point is to allow me to specify a property of an object with an NSString, then set/get that property value using KVC (i.e. valueForKey: or setValue:forKey:). But it seems like the fact that there's no way to specify (or grab) the value of the property in a generic-enough manner would be a problem - anyone using it would still have to know the data type of the property they want to access, and thus they might as well just use the accessors. I can see this would work if ObjC had a generic data type (like the 'variant' data type in VB/REALbasic), but AFAIK, ObjC doesn't have such, and valueForKey: returns an id, right?
>> How can I determine what I get back? (i.e. what does the id pointer point to? an NSString? an NSNumber? NSDecimalNumber? NSData? another NSObject subclass?)
>
> id *is* ObjC's “variant” type. You can determine the type of the underlying data by first determining its class (e.g.: [obj isKindOfClass:[NSString class]]), and then going from there. Scalar or composite values are wrapped in the appropriate classes—e.g.: NSNumber for numeric values and NSValue for generic data. The whole system is really quite flexible, particularly when you consider that ObjC, unlike so many other languages, doesn't choke on Nil values.
>
>
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.
What I'm trying to do is make a game engine that is generic enough that client code can call their properties whatever they want as long as they wrap the "effects" to apply on those objects with the appropriate key path (for example gameEngine.player.health) if the coder created an @property on the player class called "health". They could also call it "life" or "hitPoints" or "hp" or whatever, they just need to code the write key path into the 'codon' stored in the effect object. For example, an effect could be called "fireball" and do 1d6 HP to a player caught in the blast radius. My 'effect' class has an @property of type NSMutableArray (which holds 'codons' in NSStrings) of the form:
<keypath><assignment operator><value>
and the parser will check the <assignment> for '=', '+=', '-=', '*=' and '/=', evaluate the <value> portion, and pass those on to the player object via valueForKey: (to get the property's initial value before the assignment, and setValue:forKey: to set the new value.
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').
> —Mt.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden