std.serialization

[Jacob Carlborg]

On 2014-02-13 23:56, Orvid King wrote:
> Well, I wrote the code for this a while back, and although it was
> originally intended as a replacement for just std.json (thus the repo
> name), it does have the framework in place to be a generalized
> serialization framework, and there is the start of xml, and bson
> implementations, so I'm releasing it as std.serialization. The JSON
> implementation is the only one I'd consider ready for production use
> however. The (de)serialization framework takes a step back and asks,
> "Why do we need pull parsers?", the answer to which is that allocations
> are slow, so don't allocate. And that's exactly what I do. The
> serializer does absolutely *no* allocations of it's own (except for
> float->string conversion, which I don't understand the algorithms enough
> to implement myself) even going so far as to create an output range
> based version of to!string(int/uint/long/ulong/etc.). And the benefits
> of doing it this way are very clearly reflected in the pure speed of the
> serializer. On my 2ghz i5 Macbook Air, it takes 50ms to serialize 100k
> objects with roughly 600k integers contained in them when compiled with
> DMD, this roughly half the time it takes to generate the data to
> serialize. Compile it with GDC or LDC and that time is cut in half. I
> have done the exact same thing with deserialization as well, the only
> allocations done are for the output objects, because there is no
> intermediate representation.

What features does it support? How does it handle:

* Arrays
* Slices
* Pointers
* Reference types
* Support for events
* Custom serialization
* Serialization of third party types

> So how do I use this greatness? Simple! import std.serialization, and
> apply the @serializable UDA to the class/struct you want to serialize,
> then call toJOSN(yourObject) and fromJSON!YourType(yourString) to your
> heart's content!

Why require a UDA?

> Now, there are other serialization libraries out there, such as orange,
> that take the compile-time reflection approach, but the amount of code
> required to implement a single format is just massive 2100 lines for the
> XMLArchive. The entire JSON (de)serialization, which *includes* both the
> lexer and parser is only 900 lines.

The reason for that might be:

1. XML is untyped unlike JSON
2. It supports quite a lot of features that most other serialization 
libraries don't support

-- 
/Jacob Carlborg