Message: 16 Date: Tue, 9 Nov 2004 09:38:35 -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: <989aceac041109063895d91c0@mail.gmail.com> Content-Type: text/plain; charset="us-ascii"
On Mon, 8 Nov 2004 19:18:13 -0500, Edward Diener <eddielee@tropicsoft.com> wrote:
The one area where C++ is weaker than other languages for design time UI, and component, development is in its lack of a general run-time reflection mechanism. That is the only area which I see that is holding it back.
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. The thing that's bugging me is that all the reflection mechanism is covered by Boost.Python because it relies on the same principles. I *think* the boost-langbinding list seems to know this, since you also need the reflection capabilities in order to support languages that aren't Python. But that list doesn't seem to have much traffic so I haven't much to go on. In order to avoid too many reinvented wheels, I'd like to see Boost.Python split neatly into two stages: (a) Reflect C++ types into C++ objects. Each type for which you provide a reflection map will correspond to exactly one property_set object, which would contain a set of property_type_info objects. (b) Expose the types to Python using the objects created by (a). Once you've made that split, then you can add: (c) Expose the types to Lua using the objects created by (a). (d) Expose the types to <language-of-your-choice> using the objects created by (a). (e) Serialise the types, using results of (a). (f) Bind types to GUI objects, using results of (a). (g) ... you get the point. George