Range interface for std.serialization

[Dmitry Olshansky]

25-Aug-2013 23:15, Dicebot пишет:
> On Sunday, 25 August 2013 at 08:36:40 UTC, Dmitry Olshansky wrote:
>> Same thoughts here.
>> Serializer is an output range for pretty much anything (that is
>> serializable). Literally isOutputRange!T would be true for a whole lot
>> of things, making it possible to dumping any ranges of Ts via copy.
>> Just make its put method work on a variety of types and you have it.
>
> Can't it be both OutputRange itself and provide InputRange via
> `serialize` call (for filters & similar pipe processing)?

I see that you potentially want to say compress serialized data on the 
fly via some range-based compressor. Or send over network... with some 
byChunk(favoriteBufferSize) or rather some kind of adapter that outputs 
no less then X bytes if not at end. Then indeed it becomes awkward to 
model a 'sink' kind of range as it is a transformer (no matter how 
convenient it makes putting stuff into it).

It looks like the serializer has 2 "ends" - one accepts any element 
type, the other produces ubyte[] chunks.

A problem is how to connect that output end, or more precisely this puts 
our "ranges are the pipeline" idea into an awkward situation. Basically 
on the front end data may arrive in various chunks and ditto on the 
output. More then that it isn't just an input range translation to 
ubyte[] (at least that'd be very ineffective and restrictive). But I 
have an idea.

With all that said I get to the main point hopefully. here is an example 
far simpler then serialization.

No matter how we look at this there has to be a way to connect 2 sinks, 
say I want to do:

//can only use output range with it
formattedWrite(compressor, "Hey, %s !\n", name);

And have said compressor use LZMA on the data that is put into it, but 
it has to go somewhere. Thus problem of say compressing formatted text 
is not solved by input range, nor is the filtering of said text before 
'put'-ing it somewhere.

What's lacking is a way to connect a sink to another sink.

My view of it is:
auto app = appender!(ubyte[])();
//thus compression is an output range wrapper
auto compressor = compress!LZMA(app);

In other words an output range could be a filter, or rather forwarder of 
the transformed result to some other output range. And we need this not 
only for serialization (though formattedWrite can arguably  be seen as a 
serialization) but anytime we have to turn heterogeneous input into 
homogeneous output and post-process THAT output.

TL;DR: Simply put - make serialization an output range, and set an 
example by making archiver the first output range adapter.

Adapting the code by Jacob (Alternative AO2)

auto archiver = new XmlArchive!(char)(outputRange);
auto serializer = new Serializer(archiver);
serializer.put(new Object);
serializer.put([1, 2, 3, 4]); //mix and match stuff as you see fit

And even
copy(iota(1, 10), serializer);

Would all work just fine.

-- 
Dmitry Olshansky