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