[boost] Re: Serialization Library Review

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2002-11-26 04:52:15

> Date: Mon, 25 Nov 2002 05:14:23 -0500
> From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
>
> >> 5.2 "registration" - A brief recap:
> > You did not comment on my Issue 1 and proposition to completely separate
> >registration into template parameter. This way you won't need any macro.
The
> >user will choose what kind of registration system he prefer at the
laterstage.
>
> The description in "Major[Issue 1:]" really wasn't complete enough for me
> to understand.  If Registration policy is a Trait which template is it

Policy is never Trait. Just to clarify tereminology.

> applied to?   If its serialation<T, RegistrationTraitClass> ? that would
be
> quite awkward to me.
>
> But honestly, I really didn't think about it too much as I feel the whole
thing had
> gotten blown way out of proportion.   This issue only occurs when
serialization
> polymorphic classes through pointers.  For me the "forward_declaration"
> appoach works just fine and is totally hassle free. If the "forward
declaration" doesn't
> suit one's taste he can use his own string. I just used a macro so the
class name
> could be the default string.

You did not get it. I want to *completely* separate registration/type
information from serilization. For example void_cast facility hould not
mention type_info either (In fact as described in my comments it should nt
be mentioned anywhere). Once you will finish this rest will be easy cause in
serilization system you would not need to bother at all how registration is
working.

parameterized until you really get your hand to it.  BTW I do not think you
will need to parameterize serialization: should be enough to switch to
template member function.

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

> Robert Ramey

Gennadiy.