On Sunday, 3 August 2014 at 07:16:05 UTC, Andrei Alexandrescu
wrote:
We need a better json library at Facebook. I'd discussed with
Sönke the possibility of taking vibe.d's json to std but he
said it needs some more work. So I took std.jgrandson to proof
of concept state and hence ready for destruction:
http://erdani.com/d/jgrandson.d
http://erdani.com/d/phobos-prerelease/std_jgrandson.html
Here are a few differences compared to vibe.d's library. I
think these are desirable to have in that library as well:
* Parsing strings is decoupled into tokenization (which is lazy
and only needs an input range) and parsing proper. Tokenization
is lazy, which allows users to create their own advanced (e.g.
partial/lazy) parsing if needed. The parser itself is eager.
* There's no decoding of strings.
* The representation is built on Algebraic, with the advantages
that it benefits from all of its primitives. Implementation is
also very compact because Algebraic obviates a bunch of
boilerplate. Subsequent improvements to Algebraic will also
reflect themselves into improvements to std.jgrandson.
* The JSON value (called std.jgrandson.Value) has no named
member variables or methods except for __payload. This is so
there's no clash between dynamic properties exposed via
opDispatch.
Well that's about it. What would it take for this to become a
Phobos proposal? Destroy.
Andrei
I like it. Here's what I think about it.
* When I wrote my JSON library, the thing I wanted most was
constructors and opAssign functions for creating JSON values
easily.
JSON x = "some string"; You have this, so it's great.
* You didn't include an 'undefined' value like vibe.d, which is a
very
minor detail, but something I dislike. This is good.
* I'd just name Value either 'JSON' or 'JSONValue.' So you can
just import the module without using aliases.
* opDispatch is kind of "meh" for JSON objects. It works until
you hit a name clash with a UFCS function. I don't mind typing
the extra three characters.
That's all I could think of really.
