Re: [boost] Re: Serialization Library Review

From: Matthias Troyer (troyer_at_[hidden])
Date: 2002-11-26 12:12:50

Robert,

As you view binary archives as an extension to a basic serialization 
library, which I can submit but which can be kept separate from the 
core functionality - so can the polymorphic pointer 
registration/serialization be viewed as an extension to a basic 
serialization library that provides the additional feature of allowing 
serialization of polymporphic pointers.

Separating this out into a different header would make the design much 
more transparent, and users who want their won registration system can 
just swap yours with theirs and still profit from the rest of the 
serialization library.

Matthias

On Tuesday, November 26, 2002, at 05:20 PM, Robert Ramey wrote:

> Date: Tue, 26 Nov 2002 04:52:15 -0500
> From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
>
>>> Some more elaborate registration system might be interesting and/or
>>> useful, and presumably some unique id could be passed to the
>>> serialization package,  but beyond that it doesn't have to be used
>>> by the serialization system in any way.
>
>> The point is not to make "more eleborate" restration system. The 
>> point is to
>> separate it so that serilization will rely on some public interface 
>> only and
>> should not need to know implementation details.
>
>>>
>>> Nothing more is needed by the system so I don't see any benefit in 
>>> adding
>>> in any more machinery of any kind.
>
>> The benefit is more flexible design, where you could switch to 
>> different
>> registration system without changing single byte in serialization 
>> library
>> code.
>
> the system to relate a type T to an integer encoded inside an archive 
> and vice-versa
> is completely internal to the serialization system.  Once it works, 
> there
> can be no motivation to change it.  If there is a better system, then 
> it
> should be rolled into the library.  I can see no reason why one would
> want to be able to switch between strictly internal implementations.
>
> The void_cast is something else and really separate from serialization 
> -
> though serialization depends upon it. In this case, "registration" 
> refers
> to saving information about class inheritance.  This is totally 
> disjoint
> from serialization.  It is really implementation of a small part of
> reflection.  If relection is implemented as a nice package, then
> void_cast would end up as part of that.  It has nothing to do with
> the difference of opinion between "forward_declaration" and 
> "global_registration"
>
> Robert Ramey
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost