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.
