On Thursday, 16 April 2015 at 12:17:55 UTC, Sönke Ludwig wrote:
Am 16.04.2015 um 13:03 schrieb Jacob Carlborg:
On 2015-04-16 11:29, Sönke Ludwig wrote:
I'd like to let that be part of a more general serialization
framework
in top of this package instead of integrating a simplistic
custom
solution that will then later be obsoleted.
I was thinking about some low level primitives that a
serialization
library could use. Types that cannot be broken in to smaller
parts,
integer, bool and so on.
Having said that, you can go through JSONToken instead of
JSONValue
for lower (computational) overhead.
Something like?
JSONToken token;
token.number = 3;
token.kind = JSONToken.Kind.number;
toJSON(token);
Yes, just without setting the kind explicitly (it's set
automatically by assigning to the number property). Instead of
toJSON(), writeJSON() would probably be more appropriate to
avoid additional allocations.
Or what would you recommend a serialization library used?
The simplest target for a serialization library would be to
generate a stream of JSONParserNodes. That way the serializer
doesn't have to keep track of nesting levels and can reuse the
pretty printing functionality of stdx.data.generator.
However, this currently requires an input range of
JSONParserNodes, which looks like it is suboptimal for a
serializer (either requires an explicitly allocated node array,
or a strange serializer architecture that directly works as an
input range). For that reason I'm thinking about providing an
output range interface like so:
auto dst = appender!string;
auto rng = jsonOutputRange(dst);
JSONParserNode n;
// start an object
n.kind = JSONParserNode.Kind.objectStart;
rng.put(n);
// write a single entry "foo": 10.5
n.key = "foo";
rng.put(n);
rng.put(10.5);
// write another entry "bar": true
n.key = "bar";
rng.put(n);
rng.put(true);
// finish the object
n.kind = JSONParserNode.Kind.objectEnd;
rng.put(n);
writefln("JSON: %s", dst.data);
What do you think?
BTW, looks like JSONToken could use a set of constructors for
more convenient in-place construction.
I think serialiastion for this JSON library should probably be
considered out of scope until we have a general serisalisation
API. Then once we have both, we can marry the two together. So as
you say, the support from your end seems to be there. There just
needs to be a serialiser to hook into it.
