std.data.json formal review

[Don via Digitalmars-d]

On Tuesday, 28 July 2015 at 22:29:01 UTC, Walter Bright wrote:
> On 7/28/2015 7:07 AM, Atila Neves wrote:
>> Start of the two week process, folks.
>
> Thank you very much, Sönke, for taking this on. Thank you, 
> Atila, for taking on the thankless job of being review manager.
>
> Just looking at the documentation only, some general notes:
>
> 1. Not sure that 'JSON' needs to be embedded in the public 
> names. 'parseJSONStream' should just be 'parseStream', etc. 
> Name disambiguation, if needed, should be ably taken care of by 
> a number of D features for that purpose. Additionally, I 
> presume that the stdx.data package implies a number of 
> different formats. These formats should all use the same names 
> with as similar as possible APIs - this won't work too well if 
> JSON is embedded in the APIs.
>
> 2. JSON is a trivial format, http://json.org/. But I count 6 
> files and 30 names in the public API.
>
> 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. To create output:
>
>     auto r = ast.toChars();  // r is an InputRange of characters
>     writeln(r);
>
> So, we'll need:
>     toJSON
>     toChars
>     JSONException
>
> 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.

Related to this: it should not be importing std.bigint. Note that 
if std.bigint were fully implemented, it would be very 
heavyweight (optimal multiplication of enormous integers involves 
fast fourier transforms and all kinds of odd stuff, that's really 
bizarre to pull in if you're just parsing a trivial little JSON 
config file).

Although it is possible for JSON to contain numbers which are 
larger than can fit into long or ulong, it's an abnormal case. 
Many apps (probably, almost all) will want to reject such numbers 
immediately. BigInt should be opt-in.

And, it is also possible to have floating point numbers that are 
not representable in double or real. BigInt doesn't solve that 
case.

It might be adequate to simply present it as a raw number (an 
unconverted string) if it isn't a built-in type. Parse it for 
validity, but don't actually convert it.