On Tue, 09 Nov 2004 22:29:06 +0200, John Torjo <john.lists@torjo.com> wrote:
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.
Not sure if I understood you correctly, but if I did, why not do this:
// define globals in a source file
// etc. reflected_property r1(&window::get_enabled, &window::set_enabled, "enabled"); reflected_property r2(&window::get_visible, &window::set_visible, "visible");
How would one go about associating all of the reflected_properties with the "window" class regardless of their type? I am imagining a repository of properties that users can query and enumerate, e.g.: typedef vector<reflected_property> prop_list; prop_list props = reflection::get_properties ("gui::window"); for (prop_list::const_iterator i = props.begin (); i != props.end (); ++i) cout << i->first << '=' << i->second.get (); I don't see how something like this can be made to work if the reflected_property is templated on the type of data that is being reflected. Conversely, I don't see how reflected_property can be made to handle any type of data without being templated on the data type. I think this is do-able with a visitor-based approach where the reflected class (since it knows its own type info) invokes methods on a visitor object (cf. Boost.Variant visitor), but I just can understand how this can be made to work when turned on its head as in the code above. -- Caleb Epstein caleb.epstein@gmail.com