std.jgrandson

[Johannes Pfau via Digitalmars-d]

Am Sun, 03 Aug 2014 00:16:04 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> 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

API looks great but I'd like to see some simple serialize/deserialize
functions as in vibed:
http://vibed.org/api/vibe.data.json/deserializeJson
http://vibed.org/api/vibe.data.json/serializeToJson

vibe uses UDAs to customize the serialization output. That's actually
not json specific and therefore shouldn't be part of this module. But a
simple deserializeJson which simply fills in all fields of a struct
given a TokenStream is very useful and can be done without allocations
(so it's much faster than going through the DOM).

Nitpicks:

* I'd make Token only store strings, then convert to double/number only
  when requested. If a user is simply skipping some tokens these
  conversions are unnecessary overhead.
* parseString really shouldn't use appender. Make it somehow possible
  to supply a buffer to TokenStream and use that. (This way there's no
  memory allocation. If a user want to keep the string he has to .dup
  it). A BufferedRange concept might even be better, because you can
  read in blocks and reuse buffers.