std.serialization: pre-voting review / discussion

bsd slackovsky at gmail.com
Mon Aug 19 07:47:13 PDT 2013


On Sunday, 18 August 2013 at 20:33:01 UTC, Jonathan M Davis wrote:
> On Sunday, August 18, 2013 21:45:59 Jacob Carlborg wrote:
>> If versioning is crucial it can be added.
>
> I don't know if it's crucial or not, but I know that the Java 
> guys didn't have
> it initially but ended up adding it later, which would imply 
> that they ran
> into problems that made them decide that it should be there. 
> I'd certainly be
> inclined to think that it's better to have it, and it's 
> probably easier to add
> it before it's merged than later. But I don't know how crucial 
> it is.
>
> - Jonathan M Davis

I think this versioning idea is more important for protocol 
buffers, msgpck, thrift like libraries that use a separate IDL 
schema and IDL-compiled code. std.serialization uses the D code 
itself to serialize so the version is practically dictated by the 
user. It may as well be manually handled....as long as it 
throws/returns error and doesn't crash if one tries to 
deserialize an archive type into a different/modified D type.

 From memory the Protocol Buffers versioning is to ensure schema 
generated code and library are compatible. You get compile errors 
if you try to compile IDL generated code with a newer version of 
the library. Similarly you get runtime errors if you deserialize 
data that was serialized with an older version of the library. 
This is all from memory so I could be wrong...

Orange seems/feels more like the BOOST.serialization to me but 
much better. It's D for a start and allows custom archive types. 
In BOOST, the library stores a version number in the archive for 
each class serialized. This number defaults to 0 but can be set 
by the user via a #define.

http://www.boost.org/doc/libs/1_54_0/libs/serialization/doc/tutorial.html#versioning

I think adding it later can be done without breaking existing 
API, if it is deemed necessary. It just needs to default to 0 or 
something similar when missing from an archive and ensure it 
won't clash with any fields in existing archives.



More information about the Digitalmars-d mailing list