"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.
Yes, but in Boost.Python you're really saying two things for each type: (a) Here's my type's internal structure.
Emphatically no. In Boost.Python you describe a new Python type's public interface. Its interface doesn't have to have any relationship to that of the C++ type.
(b) Here's how to present the internal structure to Python. I think this fact is slightly disguised because the two steps are both performed by the def() function.
Believe me, I understand that there are two things happening there, and the Langbinding project aims to separate those two things. But when doing language binding you are definitely *not* describing internal structure. The two things are: i. Describe the external interface to the new type. ii. Turn that interface description into an actual Python type.
But the fact that it takes pointers-to-members is a giveaway.
The fact that you are generally binding member functions (and only public ones) is also a dead giveaway. What Rene said may be true (that most types can be serialized and reconstructed through their public interface), but it's not a foregone conclusion.
Part (b) here corresponds to the extra data that you attach to exposed members, such as return_internal_reference. In a serialisation library, you're saying two things too: (a) Here's my type's internal structure. (b) Here's how to write the structure to a file, and read it back. In fact, if your classes are appropriately exposed to Python, you could just pickle them in Python and you'd be done.
*If* they expose enough information to be picklable. >>> And note that Boost.Python has explicit support for pickling, which rather strongly hints that the information you supply it for ordinary class wrapping is usually not sufficient for serialization. <<<
Maybe it would help to describe how I arrived at the idea I'm suggesting.
No offense, but probably not; you're not the first one to think that the ideas behind Boost.Python could be used to build a generalized reflection library. If you search this mailing list's history and that of the Python C++-sig I think you'll find some other conversations along these lines. It's a fine idea; I just have a hard time believing that the information you need to expose for serialization is normally the same as what you need to expose for language binding. Maybe the same front-end interface code can be used to do the exposing, but whatever the user writes for one is not going to magically work for the other. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com