stdx.data.json needs a layer on top

[Sönke Ludwig via Digitalmars-d]

Am 23.06.2015 um 14:17 schrieb Laeeth Isharc:
> It's great, but it's not quite a replacement for std.json, as I see it.
>
> The stream parser is fast, and it's valuable to be able to access it at
> a low level.
>
> However, it was consciously designed to be low-level, and for something
> else to go on top.
>
> As I understand it, there is a gap between what you can currently do
> with std.json (and indeed vibed json) and what you can do with
> stdx.data.json.  And the capability falls short of what can be done in
> other standard libraries such as the ones for python.
>
> So since we are going for a nuclear-power station included approach,
> does that not mean that we need to specify what this layer should do,
> and somebody should start to work on it?

One thing. which I consider the most important missing building block, 
is Jacob's anticipated std.serialization module [1]*. Skipping the data 
representation layer and going straight for a statically typed access to 
the data is the way to go in a language such as D, at least in most 
situations.

Another part is a high level layer on top of the stream parser that 
exists for a while (albeit with room for improvement), but that I forgot 
to update the documentation for. I've now caught up on that and it can 
be found under [2] - see the read[...] and skip[...] functions.

Do you, or anyone else, have further ideas for higher level 
functionality, or any concrete examples in other standard libraries?

[1]: https://github.com/jacob-carlborg/orange
[2]: http://s-ludwig.github.io/std_data_json/stdx/data/json/parser.html


* Or any other suitable replacement, if that doesn't work out for some 
reason. The vibe.data.serialization module to me is not a suitable 
candidate as it stands, because it lacks some features of Jacob's 
solution, such as proper handling of (duplicate/interior) references. 
But it's a perfect fit for my own class of problems, so I currently 
can't justify to put work into this either.