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