Been using it for a bit now, I think the only thing I have to say
is having to insert all of those `JSONValue` everywhere is
tiresome and I never know when I have to do it.
Atila
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've
picked up the work (a lot earlier than anticipated) and
finished a first version of a loose blend of said
std.jgrandson, vibe.data.json and some changes that I had
planned for vibe.data.json for a while. I'm quite pleased by
the results so far, although without a serialization framework
it still misses a very important building block.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
DUB: http://code.dlang.org/packages/std_data_json
The new code contains:
- Lazy lexer in the form of a token input range (using slices
of the
input if possible)
- Lazy streaming parser (StAX style) in the form of a node
input range
- Eager DOM style parser returning a JSONValue
- Range based JSON string generator taking either a token
range, a
node range, or a JSONValue
- Opt-out location tracking (line/column) for tokens, nodes
and values
- No opDispatch() for JSONValue - this has shown to do more
harm than
good in vibe.data.json
The DOM style JSONValue type is based on std.variant.Algebraic.
This currently has a few usability issues that can be solved by
upgrading/fixing Algebraic:
- Operator overloading only works sporadically
- No "tag" enum is supported, so that switch()ing on the type
of a
value doesn't work and an if-else cascade is required
- Operations and conversions between different Algebraic types
is not
conveniently supported, which gets important when other
similar
formats get supported (e.g. BSON)
Assuming that those points are solved, I'd like to get some
early feedback before going for an official review. One open
issue is how to handle unescaping of string literals. Currently
it always unescapes immediately, which is more efficient for
general input ranges when the unescaped result is needed, but
less efficient for string inputs when the unescaped result is
not needed. Maybe a flag could be used to conditionally switch
behavior depending on the input range type.
Destroy away! ;)
[1]: http://forum.dlang.org/thread/lrknjl$co7$1...@digitalmars.com