[boost] Re: Serialization Library Review

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-11-26 11:20:52

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