bwood wrote:
David Abrahams wrote:
bwood <brass@mailvault.com> writes:
Along the lines of what Lapin is thinking, I think B.Ser's "versioning" support is problematic. For example, consider wanting to move (or delete) a data member out of a type between versions 1.1 and 1.2. B.Ser needs that member to remain in the type in order to support 1.1. No, you just read it and throw it away.
if (version == 11) { type_of_deleted_member ignored; ar & ignored; } Wait a minute. The code above looks like you may have focused on deleting a member and not relocating it. "ignored" isn't coming from anywhere else with a 1.1 client and it needs to be stored somewhere. Also if a 1.2 server is sending to a 1.1 client, it doesn't matter whether the member has been deleted or relocated, it still has to send the right thing back.
This is an inherent property of the communication between an 1.2 server and an 1.1 client; any versioning system would have this problem. If you want to talk to 1.1 code, you have to be able to produce 1.1 data. This is
Peter Dimov writes: true
even
if the underlying serialization layer doesn't support versioning at all, it just makes it harder for you.
"Any versioning system would have this problem." There's an alternative approach though that doesn't have the problem. release 1.1 1.2 1.3 1.4 ----------------------------------------------------------------- class name Account Account Account_13 Account_13 The class name incorporates the release in which it was last changed. As usual, the 1.3 version of the server is required to support 1.1 clients. To do this the server is built with both the Account and Account_13 definitions. Sorry for being obvious, but it uses Accounts when talking to 1.1 clients and Account_13s when working with 1.3 clients. When only additions occur between releases, I think this hierarchy would work AccountBase | Account | Account_13 If members need to be relocated out of Account in 1.3, the hierarchy might be AccountBase / \ Account Account_13 In either case, the 1.3 server may use polymorphism and accomplish what is needed pretty simply. With a 1.1 client, it produces 1.1 data by executing what originally was 1.1 code. This is helpful from a testing perspective. The only way I can think of to introduce errors with 1.1 clients would be to accidentally use Account_13 instead of Account. I think this approach supports relocated members between releases and could be used to build systems that are easier to test than systems that use "versioning." Regards, Brian Wood http://www.webEbenezer.net PS: I don't have Le Chaud Lapin's email address. I think he might be interested in this discussion.