Re: [boost] Re: Serialization library - submission #5 and request

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-09-11 11:30:35

>Date: Wed, 11 Sep 2002 11:01:15 +0400
>From: Vladimir Prus <ghost_at_[hidden]>
>To: boost_at_[hidden]
>Subject: Re: [boost] Re: Serialization library - submission #5 and request
>Message-ID: <3D7EEA3B.6040004_at_[hidden]>
>References: <01C25908.C39B9900_at_[hidden]>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Precedence: bulk
>Message: 16

>Robert Ramey wrote:

>>>>>3) Additions to documentation to include rationale for not depending 
>>>>>on type_id
>>>>
>>>>I'm afraid I'm not convinced by either the rationale or your posts. 
>>>>For that reason plan to argue and vote against the inclusion of your 
>>>>library in the current state.
>>>>
>>>
>> 
>> I'm not sure which posts or rationale you are unconvinced by.   I can say
>> I tried to address all points raised only after careful study and consideration
>> and I am convinced that they have been addressed in the best way.  My
>> reasons for the decisions made have been documented in posts and the
>> rationale.  In the absence of new facts or observations, I see no reason to
>> make any more changes.

>I have tried hard to explain that while typeid would make archives 
>unportable between different machines (not really an issue if there's
>denamgler for type_info::name() and I think work is underway on it),
>your scheme make archives possibly unsusable between different 
>applications on the same platform and even inside the same application.

You've made this assertion before but I found no basis for it.  I asked for
a example which illustrates your contention that the current
"sequence based registration" is non-portable but none was ever forthcoming.

>I've argued that requirement to register all polymorphic classes in the 
>same order places a terrible burned on the user of your library.

I argue that it doesn't. .  I believe the current system places the minimal possible
burdan on registration - limiting the requirement to derived classes not otherwise
referred to that are serialized through pointers   I believe that the examples included
with the library support my argument.

>You've merely dismissed my concerns.

Not at all true, I have carefully considered them and in some cases made alterations
to take them into account.  In response to your observations and example about diamond 
inheritance, I made valuable improvements in the library that eliminate redundancy in
such situations.  Your observations convinced me to but register_type back in.  These
things made the library better would not have happened without your input and my
considered response to it.  The fact that we have to disagree on some issues
is not because I am dimissing your concerns.  On this final issues,  your arguments
have failed to convince me.

>>>>In addition, there was *no* real discussion on interface. I still 
>>>>would like to use 'describe', which may work in 95% of cases. I also 
>>>>have some other minor disagreements. I'm afraid we won't be able to 
>>>>come to a decision over formal review period.
>>>>
>>>
>> 
>> There was quite a bit of discussion on the interface - particularly regarding
>> the describe functionality.  I had nothing against it in priniciple, its just
>> that in practice it didn't really add anything.

>Except
>1. It's much more terse
>2. It can be used for other purposes.
>3. Finally, you can 'describe' your class without even including 
>serialization headers, which is handy if somebody want to use your
>classes without any serialization.

This was discussed in detail.  To summarize,
1. load and save are generally not symetric
2. describe left no place for const - a key point in correctness and eliminating
redundance in diamond inhertitance situations.
3. did not address base class serialization.
4. it wasn't clear how this would be applied to serialization of templates

>> 
>> 
>>>>Given that a lot of time still remains, would you be willings to 
>>>>actively discuss those issues. I really would like to have 
>>>>serialization in Boost, only don't feel that the library reached the 
>>>>level that I'd like.
>>>
>> 
>> I've been answering issues raised since april.  There has been 5 months
>> and 4 drafts.   This is ample opportunity to raise new issues.  All issues
>> raised durring this time were given much consideration.  The library
>> has surpassed its original list of objectives by a significant margin.  Its
>> been months since new issues have been raised.

>I'm sorry to say that, but "opportunity to raise new issues" is not the 
>same as actively discussing anything. If I raise an issue and discussion
>just dies, why should I raise new issues?
>I get an impression that some messages were either missed or not replyed.

I have addressed every single issue raised.  Discussions have died in some cases
because there was nothing left to be said on the issue.  In some cases we have just to agree to 
disagree.

If I may sumarize, I would say your objections boil down to
1. It is possible to add a useful "describe" facility and that such a facility is necessary
2. "sequential registration" doesn't work in the general case.

I have made my best arguements that both of these propositions are unfounded.  These
arguments are documented in posts and the rationale.  I am very disappointed that I have
been unable to convince you, as I do respect your opinion, but I don't know what else to add.  
I do believe that anyone who investigates these issues to the depth that I have (i.e. implementing
real code) would agree with me on these points.

Robert Ramey