Am 22.08.2014 00:35, schrieb Sönke Ludwig:
> 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
>   - (...)
>   - Operations and conversions between different Algebraic types is not
>     conveniently supported, which gets important when other similar
>     formats get supported (e.g. BSON)

https://github.com/D-Programming-Language/phobos/pull/2452
https://github.com/D-Programming-Language/phobos/pull/2453

Those fix the most important operators, index access and binary arithmetic.

Very nice ! I had started (and dropped) a json module based on Algebraic too. So without opDispatch you plan to use a syntax like jPerson["age"] = 10 ? You didn't use stdx.d.lexer. Any reason why ? (I am asking even if I never used this module.(never coded much in D in fact))

Am 22.08.2014 14:17, schrieb matovitch:
> Very nice ! I had started (and dropped) a json module based on Algebraic
> too. So without opDispatch you plan to use a syntax like jPerson["age"]
> = 10 ? You didn't use stdx.d.lexer. Any reason why ? (I am asking even
> if I never used this module.(never coded much in D in fact))

Exactly, that's the syntax you'd use for JSONValue. But my favorite way to work with most JSON data is actually to directly read the JSON string into a D struct using a serialization framework and then access the struct in a strongly typed way. This has both, less syntactic and less runtime overhead, and also greatly reduces the chance for field name/type related bugs.

The module is written against current Phobos, which is why stdx.d.lexer wasn't really an option. I'm also unsure if std.lexer would be able to handle the parsing required for JSON numbers and strings. But it would certainly be nice already if at least the token structure could be reused. However, it should also be possible to find a painless migration path later, when std.lexer is actually part of Phobos.

On Friday, 22 August 2014 at 12:39:08 UTC, Sönke Ludwig wrote:
> Am 22.08.2014 14:17, schrieb matovitch:
>> Very nice ! I had started (and dropped) a json module based on Algebraic
>> too. So without opDispatch you plan to use a syntax like jPerson["age"]
>> = 10 ? You didn't use stdx.d.lexer. Any reason why ? (I am asking even
>> if I never used this module.(never coded much in D in fact))
>
> Exactly, that's the syntax you'd use for JSONValue. But my favorite way to work with most JSON data is actually to directly read the JSON string into a D struct using a serialization framework and then access the struct in a strongly typed way. This has both, less syntactic and less runtime overhead, and also greatly reduces the chance for field name/type related bugs.
>

Completely agree, I am waiting for a serializer too. I would love to see something like cap'n proto in D.

> The module is written against current Phobos, which is why stdx.d.lexer wasn't really an option. I'm also unsure if std.lexer would be able to handle the parsing required for JSON numbers and strings. But it would certainly be nice already if at least the token structure could be reused. However, it should also be possible to find a painless migration path later, when std.lexer is actually part of Phobos.

Ok. I think I remember there was a stdx.d.lexer's Json parser provided as sample.

Am 22.08.2014 14:47, schrieb matovitch:
> Ok. I think I remember there was a stdx.d.lexer's Json parser provided
> as sample.
>

I see, so you just have to write your own number/string parsing routines:
https://github.com/Hackerpilot/lexer-demo/blob/master/jsonlexer.d

On Friday, 22 August 2014 at 13:00:19 UTC, Sönke Ludwig wrote:
> Am 22.08.2014 14:47, schrieb matovitch:
>> Ok. I think I remember there was a stdx.d.lexer's Json parser provided
>> as sample.
>>
>
> I see, so you just have to write your own number/string parsing routines:
> https://github.com/Hackerpilot/lexer-demo/blob/master/jsonlexer.d

It's kind of "low level" indeed...I don't know what kind of back magic are doing all these template mixins but the code looks quite clean.

Confusing :

// Therefore, this always returns false.
bool isSeparating(size_t offset) pure nothrow @safe
{
    return true;
}

On 8/22/14, 3:33 AM, Sönke Ludwig wrote:
> 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);

But does this parse the whole json into JSONValue? I want to create a Person without creating an intermediate JSONValue for the whole json. Can this be done?

On 2014-08-22 00:35, 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

* Opening braces should be put on their own line to follow Phobos style guides

* I'm wondering about the assert in lexer.d, line 160. What happens if two invalid tokens after each other occur?

* I think we have talked about this before, when reviewing D lexers. I'm thinking of how to handle invalid data. Is it the best solution to throw an exception? Would it be possible to return an error token and have the client decide what to do about? Shouldn't it be possible to build a JSON validator on this?

* The lexer seems to always convert JSON types to their native D types, is that wise to do? That's unnecessary if you're implementing syntax highlighting

-- 
/Jacob Carlborg

On Friday, 22 August 2014 at 15:47:51 UTC, Jacob Carlborg wrote:
> * I think we have talked about this before, when reviewing D lexers. I'm thinking of how to handle invalid data. Is it the best solution to throw an exception? Would it be possible to return an error token and have the client decide what to do about?

Hmm... my initial reaction was "not as default - it should throw on error, otherwise noone will check for errors". But if it's returning an error token, maybe it would be sufficient if that token throws when its value is accessed?

Am 22.08.2014 17:47, schrieb Jacob Carlborg:
> On 2014-08-22 00:35, 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
>
> * Opening braces should be put on their own line to follow Phobos style
> guides

Will do.

> * I'm wondering about the assert in lexer.d, line 160. What happens if
> two invalid tokens after each other occur?

There are actually no invalid tokens at all, the "invalid" enum value is only used to denote that no token is currently stored in _front. If readToken() doesn't throw, there will always be a valid token.

> * I think we have talked about this before, when reviewing D lexers. I'm
> thinking of how to handle invalid data. Is it the best solution to throw
> an exception? Would it be possible to return an error token and have the
> client decide what to do about? Shouldn't it be possible to build a JSON
> validator on this?

That would indeed be a possibility, it's how I used to handle it in my private version of std.lexer, too. It could also be made a compile time option.

> * The lexer seems to always convert JSON types to their native D types,
> is that wise to do? That's unnecessary if you're implementing syntax
> highlighting

It's basically the same trade-off as for unescaping string literals. For "string" inputs, it would be more efficient to just store a slice, but for generic input ranges it avoids the otherwise needed allocation. The proposed flag could make an improvement here, too.