Re: [boost] [serialization] Support for multiple class name strings

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-03-19 12:51:12

Zach Laine wrote:
> Well, this went a little off-topic, but I still would like to know why
> Robert thinks that adding aliases is a bad idea.  It seems to me that
> my mistake is a pretty likely one in the long term, and so the
> Serialization library needs to provide a way to recover from such
> mistakes, or reduce the chances of their introduction altogether (by
> removing BOOST_CLASS_EXPORT()).  At the very least, if
> BOOST_CLASS_EXPORT() is to stay, an explicit note regarding this
> pitfall should be added to the docs.  Again, I am happy to write a
> patch for the code and/or docs.

My first reaction is that its a bad idea.  But I'm open to having my
mind changed.  What I'm concerned about is the possibility that
adding such a feature would ripple down into the library making
it (even) more complex, harder to maintain, perhaps hurting
performance, etc. just to address a case which shouldn't
have occurred in the first place.  So why don't we proceed
as follows:

a) make the changes you need to make to address your
current problem.
b) When we get a look at the changes, we can decide
whether they're simple and don't complicate the library
or whether it starts a whole chain reaction.

More interesting to me would be a way to somehow
trap this situation before it gets to this point.  Something
like:

An automatic serialization regression tester.

Every time the version number is incremented, a
(automatically generated?) test file is saved under
the name ... version-1.  And the all the version
test files version-0 through version-n are read
back to verify that backward compatibility has been
maintained.

Another idea would be that the exernal name
set with BOOST_CLASS_EXPORT be associated
with the current version number.  I don't know
how that would effect things, but it might be
a long/deep ripple effect.

So its not that I'm really opposed in principle,
I just don't want to start mucking things up
to deal with one unusual case which
is the result of programmer error.

Robert Ramey