std.jgrandson

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Sun Aug 3 07:44:05 PDT 2014


On 8/3/14, 1:02 AM, Johannes Pfau wrote:
> 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

Agreed.

> 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).

Nice.

> 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.

Well... this is tricky. If the input has immutable characters, they can 
be stored because it can be assumed they'll live forever. If they're 
mutable or const, that assumption doesn't hold so every number must 
allocate. At that point it's probably cheaper to just convert to double.

One thing is I didn't treat integers specially, but I did notice some 
json parsers do make that distinction.

> * 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.

Good suggestion, thanks.


Andrei




More information about the Digitalmars-d mailing list