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

From: David Abrahams (dave_at_[hidden])
Date: 2005-11-26 21:47:27

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

> David Abrahams wrote:
>> "Robert Ramey" <ramey_at_[hidden]> writes:
>>
>>> a) its short The total (actually one half - the save part)
>>> implementation consists of 220 lines of code including comments.
>>> b) it doesn't require any alterations in the library.
>>> c) it doesn't require any alterations of existing serialization
>>> code.
>>>
>>> This completes my example.
>>
>> Robert,
>>
>> I didn't have time to do a deep analysis of what appears to be a very
>> intricate design, but:
>>
>> 1. Assuming that you meant a successful test to return a status code
>>   of zero the test you posted fails on every compiler I can find.
>
> I didn't make the load part so the demo/test only invokes the save part.
> I neglected to comment out the comparison of the saved
> and loaded data so it returns non-zero.  

Oh, I didn't realize this was just half of another test you had
written.  When it failed to run with a zero return code I just stopped
looking at it.

> Also if I were to invest more effort in it I might review things
> like names , namespaces etc.
>
> Note that the library already uses exactly this technique to add a
> polymorphic interface to any existing archive class.  So this idea
> of adding an enhancement/extention by means of an "archive adaptor"
> is pretty well established though it has never been explicitly
> described as a general technique in the way I did in the previous
> post.  For the reasons I described in the post, I do have a strong
> preference for it.  But I recognize that it may seem foreign and
> unfamiliar to many programers.

There's nothing the least bit unfamiliar to me about it.  

> I sent a previous verserion to Matthias some weeks ago as a
> suggestion but apparently it wasn't convincing.  I felt I had done
> all I could.  So I was inclined to just let it rest.

> Unfortunately, this was unfairly characterised as "dismissing
> someone else's concerns" 

Uh, no, neither working on an alternative design nor stopping your
work on it was characterized as "dismissing someone else's concerns."

> Now that the bitwise optimization has come about as an example, and
> I was brow beat into making the whole solution and memo, 

I don't see how you can say you were browbeaten into it.  I tried to
tell you that it probably wouldn't make much difference and we really
want to discuss something other than the design details.  How could
that possibly be construed as pressure to make the solution and demo?

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?

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.

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