Range interface for std.serialization

[Jacob Carlborg]

On 2013-08-26 11:23, Dmitry Olshansky wrote:

> Array or any container should do for a range.

But then it won't be lazy, or perhaps that's not a problem, since the 
whole deserializing should be lazy.

> I'm not 100% sure what kind of interface to use, but Serializer and
> Deserializer should not be "shipped in one package" as in one class.
> The two a mirror each other but in essence are always used separately.
> Ditto about archiver/unarchiver they simply provide different
> functionality and it makes no sense to reuse the same object in 2 ways.
>
> Hence alternative 1 (unwrapping that snippet backwards):
>
> //BTW why go new & classes here(?)

The reason to have classes is that I need reference types. I need to 
pass the serializer to "toData" and "fromData" methods that can be 
implemented on the objects being (de)serialized. I guess they could take 
the argument by ref. Is it possible to force that?

> auto unarchiver = new XmlUnarchiver(someCharRange);
> auto deserialzier = new Deserializer(unarchiver);
> auto obj = deserializer.unpack!Object;
>
> //for sequence/array in underlying format it would use any container
> List!int list = deserializer.unpack!(List!int);
> int[] arr = deserializer.unpack!(int[]);
>
> IMO looks quite nice. The problem of how exactly should a container be
> filled is open though.
>
> So another alternative being more generic (the above could be consider
> convenience over this one):
>
> Vector!int ints;
> deserilaizer.unpackRange!(int)(x => ints.pushBack(x));
>
> Basically unpack next sequence of data (as serialized) by feeding it to
> an output range using element type as param. And a simple lambda
> qualifies as an output range.

Here we have yet another suggestion for an API. The whole reason for 
this thread is that people weren't happy with the current interface, 
i.e. not range based. Now we got probably just as many suggestions as 
people who have answered to this thread. I still don't know hot the API 
should look like.

> Also take a look at the new digest API. I have an understanding that
> serialization would do well to take the same general strategy - concrete
> archivers as structs + polymorphic interface and wrappers on top.

I could have a look at that.

> I'm still missing something about separation of archiver and serializer
> but in my mind these are tightly coupled and may as well be one entity.
> One tough little thing to take care of in std.serialization is how to
> reduce amount of constant overhead (indirections, function calls,
> branches etc.) per item. Polymorphism is easily achieved on top of fast
> and tight core the other way around is impossible.

-- 
/Jacob Carlborg