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.
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.
