Okay, I think there's a misunderstanding here. In this case - as the writer
of the game engine - I don't know (nor should I care) what the interface to the
model objects is - as long as the developer of said model objects codes the
keys into my game engine, it should be able to manipulate the model object(s)
according to the 'effects' the coder feeds into the game engine - KVC should do
the rest. The parser in the game engine though, should check (somehow) to see
if the value assigned in the 'effect' can be put into the property specified in
the 'key' so that I can issue a scripting error (or raise an NSException) if
they types are incompatible (in my case, I want the parser to be even more
strict than C itself and warn if they assign an integer to a float, or vice
versa.
I'm wondering if there's some way to use introspection to figure out the
(primitive) type of a property, such as 'int', 'float', 'char', or 'BOOL'
without having to load the model classes with unnecessary complexity (i.e. keep
the complexity in one place - the game engine.)
On Jul 18, 2012, at 10:09 PM, Graham Cox wrote:
>
> On 19/07/2012, at 1:33 AM, Alex Zavatone wrote:
>
>> Ah, yes, when coding, of course. For some reason, I was expecting that
>> during runtime/debugging, if you know the name of an object or you are
>> accessing a object your coworker wrote there was some concept that instantly
>> told you its class and makeup.
>
>
> Well, there is - you can use the runtime functions to delve into the class
> hierarchy of an object.
>
> But that's not how you write code.
>
> If you are using code a co-worker wrote then you use the documentation that
> the co-worker provided to make use of it. And by documentation I mean the
> headers - they are the "contract" which his code promises to abide by. If a
> property is declared to return a string and it doesn't, that's a bug, pure
> and simple. The same headers told you the names of the properties - how else
> would you know them? Property declarations link a name to a type. If every
> property were typed 'id' however and you were expected to examine the type at
> runtime, then your co-worker should probably be pensioned off rather quickly.
> Where a type is returned as 'id', it means that any object can be returned,
> and that's a hint that your code should not need to care what it is, and so,
> if you find yourself needing to know, that could be a code smell that
> something's amiss in your approach.
>
> Note that -isKindOfClass only tells you whether an object is a given class or
> a subclass of it, it returns a BOOL. So it's only there to confirm what you
> already expect, or to reject silly mistakes, like passing in the wrong kind
> of object to something that must have another kind.
>
> If you do something like this:
>
> NSString* theType = NSStringFromClass([someObject class]);
>
> if([theType isEqualToString:@"classTypeA"])
> {
> [self doStuffForClassAType:someObject];
> }
> else if( [theType isEqualToString:@"classTypeB"])
> {
> [self doStuffForClassBType:someObject];
>
> }
> else if .....
>
>
> then that's really violating the spirit and intention of object-oriented
> programming.
>
>
> --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
