[boost] General reflection library? (was: Re: GUI Library Proposal for a Proposal)

From: George van den Driessche (grebe_at_[hidden])
Date: 2004-11-10 10:14:56

> Message: 7
> Date: Tue, 9 Nov 2004 13:16:05 -0500
> From: Caleb Epstein <caleb.epstein_at_[hidden]>
> Subject: Re: [boost] Re: GUI Library Proposal for a Proposal
> To: boost_at_[hidden]
> Message-ID: <989aceac0411091016316d09bb_at_[hidden]>
> Content-Type: text/plain; charset=3DUS-ASCII
>
> 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]>
> >=20
> > > I've been toying with using the properties library Reece Dunn recentl=
> y
> > > 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, o=
> r
> > > is this madness?
> >=20
> > The properties are of different types, but the type information for
> > properties will always be of the same type :) So you can generate a pro=
> perty
> > 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?

Spot on. Just as a property_set corresponds to a C++ type, the
property_type_info entries in the property_set each correspond to a
pointer-to-member (or a pair of pointer-to-member-function if you want to
wrap your property with get/set methods). Just as you generate a unique
property set for each reflected type, you generate a unique property_info
for each of its properties. But since each property_info has a common base
class, you can stick them all in the same property set.

Take a peek into the Boost.Python stuff. It follows a similar pattern, I
believe.

>  What might this
> look like?

I find myself unable to write an overview of it and not almost all of it. So
I'll have to write the whole thing this evening when I have time :)

> What mechanism would you use to keep track of the type
> information?

Type information of what? You can pass around a fat pointer class which is
basically a pair< void*, property_set* > when you need to maintain knowledge
of the type of a pointer.

I'll try to get it all written up into an understandable form this evening.

George