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

On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
> Destroy away! ;)

source/stdx/data/json/lexer.d(263:8)[warn]: 'JSONToken' has method 'opEquals', but not 'toHash'.
source/stdx/data/json/lexer.d(499:65)[warn]: Use parenthesis to clarify this expression.
source/stdx/data/json/parser.d(516:8)[warn]: 'JSONParserNode' has method 'opEquals', but not 'toHash'.
source/stdx/data/json/value.d(95:10)[warn]: Variable c is never used.
source/stdx/data/json/value.d(99:10)[warn]: Variable d is never used.
source/stdx/data/json/package.d(942:14)[warn]: Variable val is never used.

It's likely that you can ignore these, but I thought I'd post them anyways. (The last three are in unittest blocks, for example.)

Someone needs to make a "showbrianmycode" bot: mention a D github repo and it runs static analysis for you.

On Thursday, 21 August 2014 at 23:27:28 UTC, Justin Whear wrote:
> Someone needs to make a "showbrianmycode" bot: mention a D github repo
> and it runs static analysis for you.

Why bother with mentioning a GitHub repo? Just make the bot periodically scan the DUB registry.

On Thursday, 21 August 2014 at 23:33:35 UTC, Idan Arye wrote:
> Why bother with mentioning a GitHub repo? Just make the bot periodically scan the DUB registry.

It's kind of picky. http://i.imgur.com/SHNAWnH.png

On 8/21/14, 7:35 PM, 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

Say I have a class Person with name (string) and age (int) with a constructor that receives both. How would I create an instance of a Person from a json with the json stream?

Suppose the json is this:

{"age": 10, "name": "John"}

And the class is this:

class Person {
  this(string name, int age) {
    // ...
  }
}

I notice in the docs there are several references to a `parseJSON` and `parseJson`, but I can't seem to find where either of these are defined. Is this just a typo?

Hope this helps: https://github.com/s-ludwig/std_data_json/search?q=parseJson&type=Code

Am 22.08.2014 02:42, schrieb Ary Borenszweig:
> Say I have a class Person with name (string) and age (int) with a
> constructor that receives both. How would I create an instance of a
> Person from a json with the json stream?
>
> Suppose the json is this:
>
> {"age": 10, "name": "John"}
>
> And the class is this:
>
> class Person {
>    this(string name, int age) {
>      // ...
>    }
> }
>

Without a serialization framework it would in theory work like this:

	JSONValue v = parseJSON(`{"age": 10, "name": "John"}`);
	auto p = new Person(v["name"].get!string, v["age"].get!int);

unfortunately the operator overloading doesn't work like this currently, so this is needed:

	JSONValue v = parseJSON(`{"age": 10, "name": "John"}`);
	auto p = new Person(
		v.get!(Json[string])["name"].get!string,
		v.get!(Json[string])["age"].get!int);

That should be solved together with the new module (it could of course also easily be added to JSONValue itself instead of Algebraic, but the value of having it in Algebraic would be much higher).

Am 22.08.2014 04:35, schrieb Colden Cullen:
> I notice in the docs there are several references to a `parseJSON` and
> `parseJson`, but I can't seem to find where either of these are defined.
> Is this just a typo?
>
> Hope this helps:
> https://github.com/s-ludwig/std_data_json/search?q=parseJson&type=Code

Seems like I forgot to replace a few mentions. They are called parseJSONValue and toJSONValue now for clarity.

Am 22.08.2014 00:48, schrieb Brian Schott:
> On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
>> Destroy away! ;)
>
> source/stdx/data/json/lexer.d(263:8)[warn]: 'JSONToken' has method
> 'opEquals', but not 'toHash'.
> source/stdx/data/json/lexer.d(499:65)[warn]: Use parenthesis to clarify
> this expression.
> source/stdx/data/json/parser.d(516:8)[warn]: 'JSONParserNode' has method
> 'opEquals', but not 'toHash'.
> source/stdx/data/json/value.d(95:10)[warn]: Variable c is never used.
> source/stdx/data/json/value.d(99:10)[warn]: Variable d is never used.
> source/stdx/data/json/package.d(942:14)[warn]: Variable val is never used.
>
> It's likely that you can ignore these, but I thought I'd post them
> anyways. (The last three are in unittest blocks, for example.)

Fixed all of them (neither was causing harm, but it's still nicer that way). Also added @safe and nothrow where possible.

BTW, anyone knows what's holding back formattedWrite() from being @safe for simple types?