Range interface for std.serialization

Jacob Carlborg doob at me.com
Wed Aug 21 11:45:47 PDT 2013


After have been reading the review thread for std.serialization I've 
been trying to figure out how a range interface for std.serialization 
could look like. There have been several suggestions how to implement 
the range interface and I feel that I really don't know that the best 
choice would be.

What I can see there are two parts of the package that makes sense to 
support the range API's. Those are the serializer (Serializer) and 
archives (Archive).

If we start with the archive and the output, used for serializing. One 
idea is to have the current method "data" return an input range.

Alternative AO1 (Archive Output 1):

auto archive = new XmlArchive!(char);
auto serializer = new Serializer(archive);
serializer.serialize(new Object);

auto inputRange = archive.data;

This is pretty straight forward and the returned range can later be used 
to write to disk or whatever the user chooses.

If this alternative is chosen how should the range for the XmlArchive 
work like? Currently the archive returns a string, should the range just 
wrap the string and step through character by character? That doesn't 
sound very effective.



Alternative AO2:

Another idea is the archive is an output range, having this interface:

auto archive = new XmlArchive!(char);
archive.writeTo(outputRange);

auto serializer = new Serializer(archive);
serializer.serialize(new Object);

Use the output range when the serialization is done.

This has the same question as the input range, should I put to the range 
character by character?



Now we come to input for the archive, used for deserializing. I think 
the only alternative is an input range. I guess this is pretty straight 
forward. The archive needs to take the range as a template parameter to 
be able to store the range.

A problem with this, actually I don't know if it's considered a problem, 
is that the following won't be possible:

auto archive = new XmlArchive!(InputRange);
archive.data = archive.data;

Which one would usually expect from an OO API. The problem here is that 
the archive is typed for the original input range but the returned range 
from "data" is of a different type.



Then it comes to the serializer. For the input to the serializer there 
is a couple of alternatives:

Alternative SI1:

auto archive = new XmlArchive!(char);
auto serializer = new Serializer(archive);
serializer.serialize(new Object);

The serializer can accept any type and will just serialize it. This is 
the current approach.

Alternative SI2:

auto archive = new XmlArchive!(char);
auto serializer = new Serializer(archive);
serializer.serialize([1,2,3,4,5].stride(2).take(2));

The serialize recognizes input ranges and treat them differently. It can 
be serialize in a couple of different ways:

* Serialize as an array
* Serialize the range as the "serialize" method has been called multiple 
times
* Found out a new structure and serialize it as a range

Alternative SI3:

auto archive = new XmlArchive!(char);
auto serializer = new Serializer(archive);
[1,2,3,4,5].stride(2).take(2).copy(serializer);

The serializer can be an output range and implement a "put" method. I 
guess this has the same problem, as alternative SI2, of how it would 
serialize the range.



For the output of the serializer (deserializing) I'm not sure if it 
makes sense to return a range. That's because you need to tell the 
serialize what root type to return:

Alternative SO1:

auto archive = new XmlArchive!(char);
auto serializer = new Serializer(archive);

serializer.serialize(new Object);

auto object = serializer.deserialize!(Object)(data);

This is the current interface.



Alternative SO2:

auto archive = new XmlArchive!(char);
auto serializer = new Serializer(archive);

serializer.serialize(new Object);

auto range = serializer.deserialize!(?)(data);

If the serializer returns a range, what type should be used in place of 
the question mark?



Conclusion:

As far as I can see there are many alternatives and I don't know which 
is best to choose.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list