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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-09-12 02:37:23

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 think I've tried to explained that in
http://aspn.activestate.com/ASPN/Mail/Message/1265629
Did you missed that message or I missed your reply?

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

I realize that you've listening to comments and did not mean to say that 
you dismissed *all* concerns --- you indeed support diamond inheritance 
now, for example. The use case in the message I refer seems still 
unaddressed, though.

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

'describe' can handle 95% of cases. It's okay to use separate load/save 
for the remaining 5%.

> 2. describe left no place for const - a key point in correctness and eliminating
 > redundance in diamond inhertitance situations.

There's a proposed solution in another message (by Michel André), and 
it's not disproved yet.

> 3. did not address base class serialization.

Not sure. You don't have to grab current scheme as is. Something like

     d.base<B>(*this).member(x).member(y)

might work.

> 4. it wasn't clear how this would be applied to serialization of templates

No comment here -- don't see problems yet.

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

Okay. We both retain our opinions.

- Volodya