[boost] Re: GUI Library Proposal for a Proposal

From: George van den Driessche (grebe_at_[hidden])
Date: 2004-11-09 12:37:15

> Message: 16
> Date: Tue, 9 Nov 2004 09:38:35 -0500
> From: Caleb Epstein <caleb.epstein_at_[hidden]>
> Subject: Re: [boost] Re: GUI Library Proposal for a Proposal
> To: boost_at_[hidden]
> Message-ID: <989aceac041109063895d91c0_at_[hidden]>
> Content-Type: text/plain; charset="us-ascii"
>
> On Mon, 8 Nov 2004 19:18:13 -0500, Edward Diener
> <eddielee_at_[hidden]> 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