std.json API improvement - Request for code review

[Robert Jacques]

On Mon, 13 Sep 2010 14:30:10 -0400, Sean Kelly <sean at invisibleduck.org>  
wrote:

> Robert Jacques Wrote:
>>
>> Hi Brain,
>> This really belongs on the phobos mailing list as JSON isn't ready for
>> public consumption yet (as far as I know). I would suspect that it even
>> has a decent chance of being dropped in favor of serialization +  
>> variant.
>> The implementation has several bugs. First, it doesn't parse Unicode
>> escape sequences correctly (e.g. \u0026). Second, JSON has no integer
>> type. Third, the serializer with certain JSON value inputs will write a
>> JSON file that can not be read by the parser. It's also missing some key
>> features, like output range and human readable output support. The  
>> design
>> is very C-ish as opposed to D-ish: its composed of a bunch of free
>> functions / types all containing JSON in their name. (i.e. parseJSON).
>> These should all be encapsulated as member functions.
>>
>> Getting more to the API itself, the reading of a JSON value is a use  
>> case
>> that just isn't considered currently. Consider:
>>
>> // It's relatively simple to write to a JSON value
>> json["vector"]["x"] = 42.8;
>>
>> // But reading it...
>> real x;
>> if(json["vector"]["x"].type == JSON_TYPE.INTEGER) {
>>      x = json["vector"]["x"].integer;
>> } else if(json["vector"]["x"].type == JSON_TYPE.FLOAT) {
>>      x = json["vector"]["x"].floating;
>> } else {
>>      enforceEx!(JSONException)(false);
>> }
>>
>> By contrast, this is the API on my personal JSON library:
>> json.vector.x = 42.8;
>> auto x = json.vector.x.number;
>
> Could all this sit atop a SAX-style API?  I'm not likely to ever use an  
> API that requires memory allocation for parsing or writing data.

Well, writing data could be done using output ranges easily enough, so no  
extra memory writing troubles there. As for parsing, the biggest cost with  
JSON is that fact that all strings can include escape chars, so things  
have to be copied instead of sliced. However, there's nothing preventing a  
SAX style implementation in the format itself. Except that JSON has less  
extra meta-data than XML so SAX becomes a less informative. Instead of:

object start vector
member x
number 42.8
object end vector

you have something like

object start
member vector
object start
member x
number 42.8
object end
object end

For myself, the files are under a mb and random access makes everything  
much faster to program and debug.