Re: [boost] some thoughts about serialisation

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-12 09:15:12

Ares Lagae <ares.lagae_at_[hidden]> writes:

> On the yahoo groups, i followed some discussions about
> a possible boost serialization library i followed them
> with great interest because im also working on a
> serialization library for what its worth (im not a
> boost developer), these are some thoughts about
> serialization:
>
> 1) Serialization is based on reflection (introspection,
> MOP, ... whatever) and to implement serialisation there
> has to be a reflection library first. Try to decouple
> serialization from reflection as much as
> possible. Because serialization needs reflection anyway
> and there are other uses for reflection, it is better
> to stay more general and decouple the two (eg one could
> use the reflection library withouth the serialzation
> lib, but not the other way around).

I *might* agree with that... but I think the amount of reflection you
say is needed below is probably more than is needed for serialization.

> 2) Reflection requires to know about properties of
> classes, like the base classes, the data members with
> their types and names, and the member functions, with
> their types and names.  For example, one could
> implement the classes Class, BaseClass<class, base>,
> DataMember<class, type>(data member pointer, name) and
> MemberFuncion<class, return, args>(member function
> pointer, name).  For each class C a method describe()
> could be implemented, making a Class<C> object, and
> adding to that object BaseClass<C, X> for all the
> baseclasses, DataMember<C, type>(data member pointer,
> name) for all the data members and MemberFuncion<C,
> return, args>(member function pointer, name) for all
> the member functions.  Aditionnaly, DataMember<class,
> type>(data member pointer, name) should have
> functionality type get() and set(type value),
> MemberFuncion<C, return, args>(member function pointer,
> name) should have functionallity retrun
> invoke(instance, args).  The Class<C> object should
> support methods like getDataMember(name) and
> getMemberFunction(name).  This describe system only
> relies on things the compiler knows at compile tyme,
> and therefor one could imagine a compiler that
> generates the describe method automatically. There is
> no need to add aditional (non static) class members,
> because reflection inherently is about classes, and not
> about class methods.
>
> 3) reflection is the difficult part, serialisation is
> the easy part. Given a reflection system, all the
> serialization method must do is query the list of data
> members, if the type of the data member is primitive,
> the data member should be serialized directly, if the
> data member is not a primitive type, we should again
> query the data members of the type, and repeating the
> process in a recursive way.  

I really don't agree with that part.  Deserializing objects without
default constructors is just one example of something you can't do
easily just because you have reflection.  Furthermore, any class with
decent encapsulation (e.g. private date members) might very well *not*
be easily adapted via introspection.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution