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

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2004-11-09 13:16:05

On Tue, 9 Nov 2004 17:37:15 -0000, George van den Driessche
<grebe_at_[hidden]> wrote:
> > Date: Tue, 9 Nov 2004 09:38:35 -0500
> > From: Caleb Epstein <caleb.epstein_at_[hidden]>
> 
> > 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_at_[hidden]