This entire thread is a really good example of why all new modules should live in exp. for a year after birth before moving to std...


On 9 May 2013 17:21, w0rp <devw0rp@gmail.com> wrote:

> On Thursday, 9 May 2013 at 01:42:41 UTC, deadalnix wrote:
>
>> Awesome. Another nice thing you can do it to use alias this on a @property to allow for implicit conversion to int.
>>
>> Overall, the API is super nice ! If performance don't matter, I definitively recommend to use the lib.
>>
>
> I'll have to experiment with the alias this idea.
>
> There are still a few things I need to work out. I'm missing an overload for opCmp (plus the host of math operators), and the append behaviour is perhaps strange. I had to choose between ~ meaning a JSON array is added to the LHS, [] ~ [1, 2] == [[1, 2]], or an array is concatenated, like the normal D arrays, [] ~ [1, 2] == [1, 2]. I went with the former for now, but I might have made the wrong choice. It all came about because of this.
>
> auto arr = jsonArray();
>
> arr ~= 1; // [1]
> arr ~= "foo"; // [1, "foo"]
> arr ~= jsonArray() // Currently: [1, "foo", []]
>
> auto another = jsonArray();
> another ~= 3;
>
> arr.array ~= another.array; // Always: [1, "foo", [], 3]
>
> I swear that I wrote a concat(JSON, JSON) function for this, but it's not there. That would have accomplished this:
>
> arr.concat(another)
>

07.05.2013 11:29, 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.

Good luck as my personal attempt to improve std.json to at least this:
https://github.com/D-Programming-Language/phobos/pull/1206#issuecomment-14826562
got stuck on even this simple pull:
https://github.com/D-Programming-Language/phobos/pull/1263

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

I have been working on a few improvements to the library. First, I made a few performance tweaks. Aside from very small (and therefore hard to describe) tweaks, I made two major improvements.

1. Manual parsing of numbers has been implemented.
2. When the input is a string, the indices and the length are used instead of the array InputRange functions.

The first one is a dangerous idea, but my unit tests show that at least what I have tested works. The reasoning behind it is that before, a string buffer (Appender!string) was created for numbers, and then one of parse!long or parse!real was chosen based upon whether or not the parser figured out it was an integer or not. Now it will read the input into actual numbers as it goes and then spit out an integer or a floating point number after it hits the end. You need to put a helmet on, but there's less allocation along the way. Perhaps this idea could be better encapsulated at some point with an std.conv function which accepts a range and returns a tagged union.

The second improvement is actually pretty nice, because I already wrapped the input range functions in methods anyway, so it was a simple matter of inserting 'static if ... else' to flip the string optimisation on. Perhaps it is better in general to wrap strings in range structs than to rely on std.array's range functions.

The end result is that I can now cheat at my own benchmark.

---
Ran for 100 runs

std.json : 674 ms
vibe.data.json : 604 ms
json : 548 ms
---

Which I updated slightly to match some function renaming (plus to correct my earlier embarrassing omission of .msecs) here: http://pastebin.com/KciFit4b

It's not a complete test of speed, and as always with benchmarks, mileage will vary.

In addition to these things, I made a few of the property and function names a little nicer, and generally improved on the documentation, which currently looks a little like this. http://www.mediafire.com/?q5lwtj2cc22s1t0 I apologise for my current lack of hosting. (I plan to correct this at a later date, perhaps with a website written in D!)

On Tuesday, 14 May 2013 at 20:23:42 UTC, w0rp wrote:
> It's not a complete test of speed, and as always with benchmarks, mileage will vary.
>
> In addition to these things, I made a few of the property and function names a little nicer, and generally improved on the documentation, which currently looks a little like this. http://www.mediafire.com/?q5lwtj2cc22s1t0 I apologise for my current lack of hosting. (I plan to correct this at a later date, perhaps with a website written in D!)


Awesome. I want to try that lib next time I have to do some code involving JSON.