std.data.json formal review

Sönke Ludwig via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 29 01:37:25 PDT 2015


Am 29.07.2015 um 07:43 schrieb Walter Bright:
> On 7/28/2015 3:55 PM, Walter Bright wrote:
>>> 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).
>>
>> That is a good point.
>
> So it appears that JSON can be in one of 3 useful states:
>
> 1. a range of characters (rc)
> 2. a range of nodes (rn)
> 3. a container of JSON values (values)
>
> What's necessary is simply the ability to convert between these states:
>
> (names are just for illustration)
>
>     rn = rc.toNodes();
>     values = rn.toValues();
>     rn = values.toNodes();
>     rc = rn.toChars();
>
> So, if I wanted to simply pretty print a JSON string s:
>
>     s.toNodes.toChars();
>
> I.e. it's all composable.

There are actually even four levels:
1. Range of characters
2. Range of tokens
3. Range of nodes
4. DOM value

Having a special case for range of DOM values may or may not be a 
worthwhile thing to optimize for handling big JSON arrays of values. But 
there is always the pull parser for that kind of data processing.

Currently not all, but most, conversions between the levels are 
implemented, and sometimes a level is skipped for efficiency. The 
question is if it would be worth the effort and the API complexity to 
implement all of them.

lexJSON: character range -> token range
parseJSONStream: character range -> node range
parseJSONStream: token range -> node range
parseJSONValue: character range -> DOM value
parseJSONValue: token range -> DOM value (same for toJSONValue)
writeJSON: token range -> character range (output range)
writeJSON: node range -> character range (output range)
writeJSON: DOM value -> character range (output range)
writeJSON: to -> character range (output range)
(same for toJSON with string output)

Adding an InputStream based version of writeJSON would be an option, but 
the question is how performant that would be and how to go about 
implementing the number->InputRange functionality.



More information about the Digitalmars-d mailing list