I reviewed the original MetaClass system code I had working. To mkae it work with the query system I think it'll be better to strip it down and start from scratch. It's possible to start implementing this new stuff now, but I would rather have it built up with this in mind. I can say that the original MetaClass system is useful, but has some annoying issues that I would want to work out.
For example, it's impossible to add per-object attributes at runtime; something that is fine for C++ but for this system it's undesirable. It's also too C++ like in its nature; I have the concept of 'classes' as an integral part of the system, methods are also separate from the normal attributes of the object. For the system to function as desired I'll need to remove this and implement a more flexibile system. The current attribute setup is interesting, I have an 'Attribute' class and an AttributeValue class being derived from it. This idea was to separate the data from the actual attribute - which is fine - but it's a little too restrictive in nature. Instead of inheritance, I'll use composition and store the AttributeValue as a member of the Attribute class. This will allow easy swapping of the values for attributes, even to the point of dropping in an entirely new typed value.
Seeing phantom talk about the concept of a Lua functor reminds me of the original idea behind my metaclass system. The first concept was to provide a 'class' system in C++ that was scripting system agnostic. You would specify your metaclass types, complete with attributes and methods and then operate on them using the API I provided. Admittedly, it didn't provide much of a bonus in 'pure' C++ environments as the extra level of indirection reduced the speed of the system and didn't offer anything else unless you needed 'pure data' classes that could be specified at runtime. However when you couple this idea with the notion of scripted methods it adds a lot more power by opening up the possibility to call scripted methods specified in any bound language. You could even call C++ specified methods or methods via a form of RPC as the marshalling process is somewhat the same - convert native metaclass properties / objects to a form understood by the other system.
So what happened to the prototype system? Quite simply, I started getting bogged down in my own VM implementation as I wanted a custom script system to power it - something that effectively stalled the project. By loosening the original design to incorporate the query interface I've effectively nullified the design of proposed scripting language for the system and been forced to revaluate how it'll be used. This is actually a blessing in disguise as I am now free to work on developing a useful system that reiterates my original goal of it being language agnostic.
So the system in a nutshell:
The 'metaclass' system name will be dropped; instead I will be referring to it as the Entity Object system (at least for now). The overall goal is to allow for complete data-driven game architectures to be formed around it.
This system is all well and good, but now I want some feedback from you guys. Specifically, how would you use this system? What would you use it for? Can you provide examples, if possible?
Usage examples will help when I'm rebuilding the prototype as it'll allow me to begin catering the system to some real-world scenarios instead of building it in isolation.