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