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.
