Re: [boost] [serialization] Enhancing Archives with Archve Adaptors

From: David Abrahams (dave_at_[hidden])
Date: 2005-11-26 23:59:42

"Robert Ramey" <ramey_at_[hidden]> writes:

>> I'd really appreciate it if you could answer this question from my
>> previous post:
>>
>>  2. Is this the promised simplification of the design we posted in
>>     http://lists.boost.org/Archives/boost/2005/11/97002.php?  If so,
>>     by what measure is your approach a simplification?
>
> Honestly,  I don't remember what it was specfically in response to.

In http://lists.boost.org/Archives/boost/2005/11/97201.php you wrote:

  Shortly, I'll post some code that I believe addresses all your
  design goals in a much simpler and effective way.

I'm asking if the code you just posted represents that promised
simplification.

> It was intended to illustrate my view that the library can and should
> be extended without adding things to base classes

That it _can_ be so extended has been well established.  We know that
it is possible since
http://lists.boost.org/Archives/boost/2005/11/97002.php also extends
the library without adding anything to base classes.

> and finally that it simpler and more effective to do it this way.

We believe there are some aspects of "effectiveness" that you haven't
yet considered.  We'd like to discuss those with you.

> The code attached implements all of the save_array functionality
> included in mattias system (actually more) in far fewer lines of
> code and with the benefits described in the posts.

By "mattias system" I suppose you're referring to something proposed
before 11-21-2005?  Are you simply refusing to look at the code we
have replaced that proposal with (only 159 lines posted including
extensive comments which are mostly exposition)?  

The point of that code was to present something that wouldn't modify
the existing library so that you could be comfortable thinking about
the consequences of a non-intrusive design without thinking we were
trying to make changes in your library.  Our 159 lines are much
shorter and simpler than what you just posted; it should be easier to
think about the effects of using the smaller system.

>> And also, I'd appreciate it if you'd respond to the paragraph below.
>>
>>  I actually don't want to get into a discussion of which non-intrusive
>>  design is best.  The social and code interoperability dynamics of any
>>  non-intrusive design are the same, and that's really what I want to
>>  discuss.  Please let me know when you're ready to talk about that.
>
> Sorry,  I don't even know what that means.

It means I want to discuss what happens when the people implementing
serialization functions for specific classes are not the same people
choosing the archive that will be used, and what happens when there is
a second, "non-official" interface to the serialization library that
must be used whenever it's important to get the best performance.

In http://lists.boost.org/Archives/boost/2005/11/97201.php
you wrote:

  Now my question is why do you need anything from me? 

and I failed to answer.  Let me be perfectly up front about what I want:

1. I want you to understand what I believe to be the (so far
   unconsidered) consequences of the non-intrusive choice.  That's
   what I'd like to discuss next, when you are ready.

2. I want you to either:

   a. decide that you agree with us about what will probably happen,
      and that it is unpleasant enough to warrant an intrusive design,
      
   **OR**

   b. understand why we will have to encourage everyone to use the
      non-official interface instead of the one in the serialization
      library, so that there is no ill will when that happens.

If all of that fails I want the rest of the community to understand
why we are doing what we're doing so that our work will be accepted,
both by users, and -- we hope -- as a separate Boost library.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com