std.jgrandson

Orvid King via Digitalmars-d digitalmars-d at puremagic.com
Sun Aug 3 13:11:49 PDT 2014


On 8/3/2014 2:16 AM, 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

If your looking for serialization from statically known type layouts 
then I believe my JSON (de)serialization code 
(https://github.com/Orvid/JSONSerialization) might actually be of 
interest to you, as it uses no intermediate representation, nor does it 
allocate when it converts an object to JSON. As far as I know, even when 
only compiled with DMD, it's among the fastest JSON (de)serialization 
libraries.

Unless it needs to convert a floating point number to a string, in which 
case I suppose you could certainly use a local buffer to write to, but 
at the moment it just converts it to a normal string that gets written 
to the output range. It also supports (de)serializing from, what I 
called at the time, dynamic types, such as std.variant, which isn't 
actually supported because that code is only there because I needed it 
for something else, and wasn't using std.variant at the time.


More information about the Digitalmars-d mailing list