Re: std.json API improvement - Request for code review

[Robert Jacques]

On Mon, 13 Sep 2010 14:30:10 -0400, Sean Kelly <s...@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.