Re: [boost] [serialization][trunk] please bring usarchive helpers back

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-09-06 11:44:57

Joaquín Mª López Muñoz wrote:

> 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.

I didn't really see this.  In large part due to the fact that no one
over the years as expressed a need for it.  The only reason
I had to add it was to accomodate design issues with smart_ptr
which makes it impossible to serialize without special help. So
I always considered it a pathalogical case.

> 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:

First of all, let me say its always a pleasure to disagree with you.

> 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.

For that one case.  I understand the situation, but as I said I felt
that was an (almost) unique situation.

> 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?

I haven't made any plans.  Even the runtime helper, I would still have
to make special code for a new shared_ptr - so its just a question of
where the code ends up.

> 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.

As, I've said, based on experience so far, I've been of the idea that
the only case where one would ever need this is shared_ptr.

So we can think about this.

Lately I've become more focused on improving performance of the
serialization library and this provided part of the motivation for 
eliminating
helpers for those who don't need them.  Another very significant issue
was that making the helper concept official would mean that I would
have to document it which would lead to people asking questions about
it which would lead to people spending a lot of time telling me how it
could/should be enhanced, and me responding, etc, etc, etc.  So I was
and still am interested in shrinking down the serialization library by
factoring that which is orthogonal to serialization.

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.

Robert Ramey