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

Message: 7 Date: Tue, 9 Nov 2004 13:16:05 -0500 From: Caleb Epstein <caleb.epstein@gmail.com> Subject: Re: [boost] Re: GUI Library Proposal for a Proposal To: boost@lists.boost.org Message-ID: <989aceac0411091016316d09bb@mail.gmail.com> Content-Type: text/plain; charset=3DUS-ASCII
Date: Tue, 9 Nov 2004 09:38:35 -0500 From: Caleb Epstein <caleb.epstein@gmail.com> =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=
On Tue, 9 Nov 2004 17:37:15 -0000, George van den Driessche <grebe@bigfoot.com> wrote: 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

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
Please also have a look at my properties/reflections approach. If there is sufficient interest I'd be happy to submit it to the boost library. The pointers here are for the entire "Lit Window Library". The reflections part is contained in the lwbase package and is available separately. Here are the pointers: Initial documentation (still incomplete) http://www.litwindow.com/lwl/doc/html/group__data__adapters__howto.html Article about "data abstraction layer" (reflections basically) http://www.litwindow.com/Library/RapidUI_Article_1/rapidui_article_2.htm Sourceforge and CVS repository: http://sourceforge.net/projects/litwindow Download the lwbase package if you are interested in the reflections only. Homepage: http://www.litwindow.com/library
participants (2)
-
George van den Driessche
-
Hajo Kirchhoff