Boost logo

Boost :

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,
> "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

Boost list run by bdawes at, gregod at, cpdaniel at, john at