David Abrahams wrote:
"George van den Driessche" <grebe@bigfoot.com> writes:
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).
This I have serious doubts about. What you'd expose for Python/Lua binding would be an object's public interface: its abstraction. In order to do serialization in that way, you'd likely have to expose an object's guts: its implementation details.
I think the assumption George is going under is that the public interface provides enough information to reconstruct the objects. Although that is not required it is a common way to design classes that are going to be serialized. So if you accept that axiom it's possible to serialize from a reflection of a public interface.
(f) Bind types to GUI objects, using results of (a).
What does it mean to bind a type to a GUI object?
This is something I somewhat do in parts of the GUI code I have. Basically it's being able to tie a variable (class member, global, etc) to be displayed and manipulated "directly" by a GUI widget. For example attaching an enum to a combo-box, or a string to a text-box. Doing something that maps from the type to the widget automatically given the reflection info of the type is not an easy task as there's more to a variable than just the type which one ends up adding when creating the widget bindings, or at least I did. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq