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
> > 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
> 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]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk