Re: [boost] [serialization][trunk]please bring us archive helpers back

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2007-09-08 08:10:37

----- Mensaje original -----
De: Robert Ramey <ramey_at_[hidden]>
Fecha: Viernes, Septiembre 7, 2007 5:42 pm
Asunto: Re: [boost][serialization][trunk]please bring us archive 
helpers back
Para: boost_at_[hidden]

> > > Perhaps the best resolution is to just make a mix-in class 
> > > equivalent to the previous helper functionality.  It would seem 
> > > to me that this would give you every thing we both need.
[...]
> Under the 1.34 helper system, a few calls were added to the class
> hierarchy at high level.  This basically added a set of pointers to
> helper classes which were handled by smart_ptr so they would
> automatically be destroyed when the archive was destroyed.
> 
> If you want this functionality in he new system
> a) create a "helper manager" class
> b) move the helper manager code from the 1.34 release
> into this new class.
> c) mixin you new "helper manager" along with "naked_text_iarchive"
> and - voila - you have the old functionality as it was before.
> 
> I'm sure this wouldn't be hard to do.

This can be done, but makes the archive types to be used dependent
on the types to be serialized!! This is a wrong approach, IMHO.
Consider the following: I have a type foo for which I need a
serialization helper, let's call it foo_ser_helper, which I
embed into B.S by means of a foo_ser_hlp_manager as you suggest:

struct foo_text_iarchive:
  naked_text_iarchive,
  foo_ser_hlp_manager
{...};

Now, the problem is that user code willing to serialize my foo
can't use a regular text_iarchive but have to resort to
foo_text_iarchive instead. This is annoying enough because I
force the user to change her code in a rather surprising way
(considering she need not change archive types for serializing
"normal" types), but things can get worse: if now some other
author provides a class bar under similar conditions:

struct bar_text_iarchive:
  text_iarchive,
  bar_ser_hlp_manager
{...};

what should someone do in order to serialize the following
data type?

struct udt
{
  foo f;
  bar b;
};

So, I think providing archive types specialized for serializing
specific types basically breaks down the architectural design
of B.S, which is based on the separation of type-agnostic
archives and archive-agnostic serialization code: this is too
good to depart from.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo