std.data.json formal review

[H. S. Teoh via Digitalmars-d]

On Tue, Jul 28, 2015 at 03:29:02PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
> 3. Stepping back a bit, when I think of parsing JSON data, I think:
> 
>     auto ast = inputrange.toJSON();
> 
> where toJSON() accepts an input range and produces a container, the
> ast. The ast is just a JSON value. Then, I can just query the ast to
> see what kind of value it is (using overloading), and walk it as
> necessary.

+1. The API should be as simple as possible.

Ideally, I'd say hook it up to std.conv.to for maximum flexibility. Then
you can just use to() to convert between a JSON container and the value
that it represents (assuming the types are compatible).

OTOH, some people might want the option of parser-driven data processing
instead (e.g. the JSON data is very large and we don't want to store the
whole thing in memory at once). I'm not sure what a good API for that
would be, though.


> To create output:
> 
>     auto r = ast.toChars();  // r is an InputRange of characters
>     writeln(r);
> 
> So, we'll need:
>     toJSON
>     toChars

Shouldn't it just be toString()?


[...]
> The possible JSON values are:
>     string
>     number
>     object (associative arrays)
>     array
>     true
>     false
>     null
> 
> Since these are D builtin types, they can actually be a simple union
> of D builtin types.
> 
> There is a decision needed about whether toJSON() allocates data or
> returns slices into its inputrange. This can be 'static if' tested by:
> if inputrange can return immutable slices. toChars() can take a
> compile time argument to determine if it is 'pretty' or not.

Whether or not toJSON() allocates *data*, it will have to allocate
container nodes of some sort. At the minimum, it will need to use AA's,
so it cannot be @nogc.


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.