Re: [boost] Re: GUI Library Proposal for a Proposal

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
caleb.epstein_at_[hidden]