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

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-09-06 05:04:46

Robert Ramey ha escrito:

> I put the archive helper in as an ad hoc solution to a particular problem.
> I was always unsatisfied with it as I didn't like the idea of decorating
> the main serialization library code with special cases.  Its my belief
> that this is what makes libraries die of old age.

As I see it, the helper interface does not litter the serialization code, it
merely provides an extension API for users implementing non-trivial
serialization schemes --note that the helper themselves are not part
of B.S but belong in the different serializable types, much like the
associated serialize() functions.

> However, at the time it seemed expedient so I included it for this one
> case (shared pointer) and left it undocumented on purpose.
>
> Eventually I found what to me is a much better solution
> and this is implemented in the next release.  This is
> to use multiple inheritance to add the helper in as a mix-in.
> This is the way I plan to support this kind of thing in
> the future.  It doesn't change the published API of the
> serialization library itself.  However I will add a
> section in the documentation - if its not already there
> describing this technique.
>
> I believe that using mix-in to ad helpers will be
> equivalent to adding them in at runtime as they are now.
>
> I included the shared_ptr helper mix-in in the in the
> library in order to not change the current api and
> in recognition of shared_ptrs priviledged status
> as a boost component.
>
> I didn't expect anyone to notice this change, as
> no one had posted a problem which required
> helpers and it was undocumented.
>

With all due respect (and admiration for your great lib) I think the mix-in
idea has many flaws as compared with the former helper interface. Let
me state several points supporting my thesis and addressing  some of
the claims you make above; I'd be grateful if you could discuss them with
me:

1. You state that the mix-in approach "doesn't change the published API
of B.S". I don't think so: if I decide to implement an Archive type I must
explicitly handle shared_ptr (or decide not to do it, I guess this is what
your naked_* archive versions are for), so definitely this shows through
the API I'm expected to implement.

2. Having an ad-hoc extension for one particular type seems to me a
recipe for disaster. Consider the following: some environments are
already providing std::tr1::shared_ptr, which of course does not have
built-in serialization capabilities. How am I supposed to serialize this?
Are you going to add another mix-in to your Archive classes to handle
this as well?

3. You say that adding mix-ins is equivalent to adding helpers, but I think
the approaches are radically different. Addition of a mix-in is
  a. made at compile time
  b. part of the implementation of the archive
while addition of a helper is
  a. made at run-time
  b. part of the serialization code for a type
Mix-in are closed for extension where helpers are open: If I need
a helper for serializing some T and I'm using an Archive whitout
special support for that T, all hope is lost.

4. IMHO the helper API in B.S 1.34 is a simple yet powerful capability,
and does not look forced or clumsy at all. It simply provides a way
to add state info to an archive object, which is in a sense a state machine
transtitioning its way during the serialization process. I contend that
helpers allow for implementing serialization for types which otherwise
would be impossible to serialize or should rely on inefficient detours:
  a. boost::shared_ptr (unless adhoc provisions are made)
  b. std::tr1::shared_ptr
  c. STL containers iterators.
  d. The lib I'm writing, which is the original cause why I started this
  thread,  provides a class called flyweight<T> where flyweights with the
  same value share their representation by holding internal pointers to the
  same T value. Serializating this is trivial with the aid of a saving helper
  that maps T*s to flyweight<T>s --without helpers, the best I can come
  up with involves T duplication in the serialization stream and inefficient
  creation of flyweights on saving time.

Of course I'm aware helpers were undocumented and I was basically
using them at my own risk, so I'm not complaining about my code
being broken by the switch from B.S 1.34 to trunk, I just want to convince
you that helpers are indeed a useful general-purpose capability that should
be made public, and that the proposed mix-in alternative is flawed.

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