On 19/07/2012, at 11:13 PM, William Squires wrote: > Okay, I think there's a misunderstanding here.
Sure. > 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.) I think part of the problem here is that you have a reasonable understanding of your problem space, and are using terminology that makes sense to you but no-one else. From this and your previous description of what you're trying to do, to be honest I'm none the wiser. Perhaps a concrete example would help, because when you talk about 'effect' I think you mean something specific your game engine implements that is not the general meaning of 'effect'. I've been trying to ignore that and give you advice based on concepts in the abstract. One of these is the general rule that in object-oriented programming, taking different code-paths based on the type of an object is avoided, and instead some common method is called on the object and that takes the necessary code path. You seem determined to break this rule, which I suggest is a bad idea. If your game engine needs to violate basic concepts like this to do its thing, it's probably not a very good design. KVC exists so that any object can be treated (in terms of its properties) in much the same way as a dictionary, and that's about it. If that's not enough, it's probably not the right technology to be basing this on. You mention that assigning an int to a float should throw an exception. Basing it on KVC and NSNumber that's not possible. You can't know from the internal type of an NSNumber what value it was created with, for example, if I assign the float value 1.0 to an NSNumber it is perfectly within its rights to store it as an integer, because that's the maximum precision it requires to represent that particular float. If you attempt to examine the obj-c type of the NSNumber, you might see integer, not float, even though the original property that was boxed into this value was a float! Asking for its -floatValue however, you get 1.0, so there's no problem with this until you expect it to to track types end-to-end for you. All I can suggest is that you don't use the automatic boxing/unboxing of scalar properties and instead force clients of your engine to return properties in some form you can always deal with, such as an object you define that embodies the data value and type information. e.g. declare a class 'WSGameEngineProperty' that can hold numbers, strings or any other value you want to work with and ask your clients to send and receive these. (Make it easy on them by defining a nice set of convenience class methods for making these using any scalar or string type). You can still use KVC to set and retrieve these, because they are object types and won't be subject to automatic boxing. In effect what you're doing is giving up on automatically detecting the data type (because you can't for numbers, and shouldn't in general) and putting that responsibility onto the programmer who is the client of your engine, who is a lot more intelligent and can always do the right thing! If that's too big a pill to swallow, another alternative could be to replace KVC with something similar of your own which converts to and from your private property type automatically (you can use @encode to detect the original type of a scalar property). That way your implementation can track the type. The only restriction would be that your clients would have to implement their objects with methods that you require, such as setGameProperty:forKey:, and -gamePropertyForKey: in place of the KVC equivalents. I still fail to see how your game engine would even be able to ask for a property without knowing what it is going to be dealing with, or is it just up to the client to push values into your engine? If the latter, the client could tell you the type through the API you define, no? --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
