From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2004-11-09 16:01:18
On Tue, 09 Nov 2004 22:29:06 +0200, John Torjo <john.lists_at_[hidden]> 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,
> reflected_property r2(&window::get_visible, &window::set_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_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk