On Tue, 9 Nov 2004 17:37:15 -0000, George van den Driessche <grebe@bigfoot.com> wrote:
Date: Tue, 9 Nov 2004 09:38:35 -0500 From: Caleb Epstein <caleb.epstein@gmail.com>
I've been toying with using the properties library Reece Dunn recently submitted (in the boost-sandbox CVS) for this purpose. I've got something very sketchy, but it relies on a visitor pattern to "pass" type information to client code in a manner similar to Boost.Variant.
I'd prefer a way of storing the type information for each reflectable class statically, and in a generic way, e.g. something like std::map<std::string, property>. This would enable the reflection code could be decoupled from the reflected classes entirely and just operate on this property meta-data. It would also allow client code to lookup individual properties (e.g. by name) instead of having to visit all of them.
I'm stumped by how to store this information in any sort of container though, since the properties are of different types. Any thoughts, or is this madness?
The properties are of different types, but the type information for properties will always be of the same type :) So you can generate a property set for your class, that includes the dictionary that maps names to property_type_info structures. Each property_type_info would be automatically generated from the static type of the property.
You lost me here. The property types each inherit from property_info, but it is similarly templated on the type of object begin stored/referenced/aliased. Are you suggesting another non-template base class which all properties would inherit from? What might this look like? What mechanism would you use to keep track of the type information?
The thing that's bugging me is that all the reflection mechanism is covered by Boost.Python because it relies on the same principles. [...]
Exactly. A reflection mechanism would facilitate lots of different language bindings, serialization, etc. -- Caleb Epstein caleb.epstein@gmail.com