I wasn't quite satisfied with std.json or the JSON libraries in frameworks. The standard library doesn't make it easy enough to create JSON objects, and my primary objection for the framework solutions is that they seem to depend on other parts of the frameworks. (I'd rather not depend on a host of libraries I won't be using just to use one I will.) So, desiring an easy-to-use and atomic library, I took to writing my own from scratch.

https://github.com/w0rp/dson/blob/master/json.d

I would love to hear some comments on my implementation. Criticism is mostly what I am after. It's hard for me to self-criticise. Perhaps the most obvious criticism to me is that I seem to write too damn many unit tests.

On Tuesday, 7 May 2013 at 07:29:16 UTC, w0rp wrote:
> ...
> https://github.com/w0rp/dson/blob/master/json.d
> ...

looks like you do reinvented the wheel. std.json already has anything we need to read/write json, and it is really small.
after all, i would enjoy the idea if someone would write std.xml like stuff for reading/writing which will be pulled to std.json.

Am 07.05.2013 09:29, schrieb w0rp:
> I wasn't quite satisfied with std.json or the JSON libraries in frameworks. The standard library doesn't make it easy enough to create JSON objects, and my primary objection for the framework solutions is that they seem to depend on other parts of the frameworks. (I'd rather not depend on a host of libraries I won't be using just to use one I will.)

Just for reference, the vibe.d JSON implementation does not depend on
other parts of the library:
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/data/json.d

On Tuesday, 7 May 2013 at 07:52:29 UTC, evilrat wrote:
> On Tuesday, 7 May 2013 at 07:29:16 UTC, w0rp wrote:
>> ...
>> https://github.com/w0rp/dson/blob/master/json.d
>> ...
>
> looks like you do reinvented the wheel. std.json already has anything we need to read/write json, and it is really small.
> after all, i would enjoy the idea if someone would write std.xml like stuff for reading/writing which will be pulled to std.json.

I always was unhappy with phobos json lib. Mostly because the API.

wOrp, can you provide some usage example, to see how the lib is intended to be used ? Do you have some benchmarks ?

Sone, same thing ?

On 2013-05-07 09:29, w0rp wrote:

> Perhaps the most obvious criticism to me is that I seem to write too damn many unit tests.

I never heard of anyone complaining about too many unit tests. I don't see it as a problem.

-- 
/Jacob Carlborg

Am 07.05.2013 09:29, schrieb w0rp:
> I wasn't quite satisfied with std.json or the JSON libraries in frameworks. The standard library doesn't make it easy enough to create JSON objects, and my primary objection for the framework solutions is that they seem to depend on other parts of the frameworks. (I'd rather not depend on a host of libraries I won't be using just to use one I will.) So, desiring an easy-to-use and atomic library, I took to writing my own from scratch.
> 
> https://github.com/w0rp/dson/blob/master/json.d
> 
> I would love to hear some comments on my implementation. Criticism is mostly what I am after. It's hard for me to self-criticise. Perhaps the most obvious criticism to me is that I seem to write too damn many unit tests.

And there is https://256.makerslocal.org/wiki/index.php/Libdjson

I'm not terribly happy with std.json do this is welcome. I do wish that there were a SAX style parser available too though, so I could parse JSON without allocating.

On May 7, 2013, at 12:52 AM, "evilrat" <evilrat666@gmail.com> wrote:

> On Tuesday, 7 May 2013 at 07:29:16 UTC, w0rp wrote:
>> ...
>> https://github.com/w0rp/dson/blob/master/json.d
>> ...
> 
> looks like you do reinvented the wheel. std.json already has anything we need to read/write json, and it is really small.
> after all, i would enjoy the idea if someone would write std.xml like stuff for reading/writing which will be pulled to std.json.

W dniu 07.05.2013 16:53, Sean Kelly pisze:
> I'm not terribly happy with std.json do this is welcome. I do wish that
> there were a SAX style parser available too though, so I could parse JSON without allocating.

You may find this useful: https://github.com/pszturmaj/json-streaming-parser

Don't be scared by the TODOs, they're not much relevant for normal usage. The only thing you shouldn't do is calling whole() methods more than once.

On Tuesday, 7 May 2013 at 17:13:18 UTC, Piotr Szturmaj wrote:
>
> You may find this useful: https://github.com/pszturmaj/json-streaming-parser

Thanks for the link.  Unfortunately, I couldn't get it to compiler out of the box.  I did use the test routine you had to benchmark std.json and the JSON implementation from the OP of this thread as well as an event-based JSON parser I implemented for work.  On a single parse of this large (189MB) JSON file:

https://github.com/zeMirco/sf-city-lots-json

Here are my results for one parse, where "newJson" is the OP's JSON parser and "jepJson" is mine:

$ main
n = 1
Milliseconds to call stdJson() n times: 73054
Milliseconds to call newJson() n times: 44022
Milliseconds to call jepJson() n times: 839
newJson() is faster than stdJson() 1.66x times
jepJson() is faster than stdJson() 87.1x times


Now obviously, in many cases convenience is preferable to raw speed, but I think code in Phobos should be an option for both types of uses whenever possible.  What I'd really like to see is the variant-type front-end layered on top of an event-based parser so the user could just use parseJSON as-is to generate a tree of JSON objects or call the event-driven parser directly when performance is desired.  I don't think the parser needs to be resumable either, since in most cases JSON is transported in an HTTP message, so a plain old recursive descent parser is fine.

On 2013-05-07 20:36, Sean Kelly wrote:

> $ main
> n = 1
> Milliseconds to call stdJson() n times: 73054
> Milliseconds to call newJson() n times: 44022
> Milliseconds to call jepJson() n times: 839
> newJson() is faster than stdJson() 1.66x times
> jepJson() is faster than stdJson() 87.1x times

That's quite a big difference.

-- 
/Jacob Carlborg