[boost] Re: Generalised reflection

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-11 17:08:53

"George van den Driessche" <grebe_at_[hidden]> 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