On Thursday, 16 April 2015 at 12:17:55 UTC, Sönke Ludwig wrote:
> Am 16.04.2015 um 13:03 schrieb Jacob Carlborg:
>> On 2015-04-16 11:29, Sönke Ludwig wrote:
>>
>>> I'd like to let that be part of a more general serialization framework
>>> in top of this package instead of integrating a simplistic custom
>>> solution that will then later be obsoleted.
>>
>> I was thinking about some low level primitives that a serialization
>> library could use. Types that cannot be broken in to smaller parts,
>> integer, bool and so on.
>>
>>> Having said that, you can go through JSONToken instead of JSONValue
>>> for lower (computational) overhead.
>>
>> Something like?
>>
>> JSONToken token;
>> token.number = 3;
>> token.kind = JSONToken.Kind.number;
>> toJSON(token);
>
> Yes, just without setting the kind explicitly (it's set automatically by assigning to the number property). Instead of toJSON(), writeJSON() would probably be more appropriate to avoid additional allocations.
>
>>
>> Or what would you recommend a serialization library used?
>>
>
> The simplest target for a serialization library would be to generate a stream of JSONParserNodes. That way the serializer doesn't have to keep track of nesting levels and can reuse the pretty printing functionality of stdx.data.generator.
>
> However, this currently requires an input range of JSONParserNodes, which looks like it is suboptimal for a serializer (either requires an explicitly allocated node array, or a strange serializer architecture that directly works as an input range). For that reason I'm thinking about providing an output range interface like so:
>
> 	auto dst = appender!string;
> 	auto rng = jsonOutputRange(dst);
>
> 	JSONParserNode n;
> 	// start an object
> 	n.kind = JSONParserNode.Kind.objectStart;
> 	rng.put(n);
>
> 	// write a single entry "foo": 10.5
> 	n.key = "foo";
> 	rng.put(n);
> 	rng.put(10.5);
>
> 	// write another entry "bar": true
> 	n.key = "bar";
> 	rng.put(n);
> 	rng.put(true);
>
> 	// finish the object
> 	n.kind = JSONParserNode.Kind.objectEnd;
> 	rng.put(n);
>
> 	writefln("JSON: %s", dst.data);
>
> What do you think?
>
> BTW, looks like JSONToken could use a set of constructors for more convenient in-place construction.

I think serialiastion for this JSON library should probably be considered out of scope until we have a general serisalisation API. Then once we have both, we can marry the two together. So as you say, the support from your end seems to be there. There just needs to be a serialiser to hook into it.

On 2015-04-16 14:28, w0rp wrote:

> I think serialiastion for this JSON library should probably be
> considered out of scope until we have a general serisalisation API. Then
> once we have both, we can marry the two together. So as you say, the
> support from your end seems to be there. There just needs to be a
> serialiser to hook into it.

I'm working on the general serialization API. I'm working on rewriting Orange [1] to get it into Phobos. I'm asking about an API for converting basic types, that cannot be further taken apart, to JSON.

[1] https://github.com/jacob-carlborg/orange

-- 
/Jacob Carlborg

On 2015-04-16 14:17, Sönke Ludwig wrote:

> The simplest target for a serialization library would be to generate a
> stream of JSONParserNodes. That way the serializer doesn't have to keep
> track of nesting levels and can reuse the pretty printing functionality
> of stdx.data.generator.
>
> However, this currently requires an input range of JSONParserNodes,
> which looks like it is suboptimal for a serializer (either requires an
> explicitly allocated node array, or a strange serializer architecture
> that directly works as an input range).

The serialization library I'm working on has an output range interface.

> For that reason I'm thinking about providing an output range interface like so:
>
>      auto dst = appender!string;
>      auto rng = jsonOutputRange(dst);
>
>      JSONParserNode n;
>      // start an object
>      n.kind = JSONParserNode.Kind.objectStart;
>      rng.put(n);
>
>      // write a single entry "foo": 10.5
>      n.key = "foo";
>      rng.put(n);
>      rng.put(10.5);
>
>      // write another entry "bar": true
>      n.key = "bar";
>      rng.put(n);
>      rng.put(true);
>
>      // finish the object
>      n.kind = JSONParserNode.Kind.objectEnd;
>      rng.put(n);
>
>      writefln("JSON: %s", dst.data);
>
> What do you think?

That looks very handy, that would be great to have.

-- 
/Jacob Carlborg

Am 07.04.2015 um 18:37 schrieb Sönke Ludwig:
> Anyone up to this? The issues of the previous discussion [1] have all
> been addressed now more or less, so the package is ready for a more
> thorough review.
>
> Code: https://github.com/s-ludwig/std_data_json
> Docs: http://s-ludwig.github.io/std_data_json/
>
> [1]:
> http://forum.dlang.org/thread/lt5s76$is$1@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com
>

So, since Dicebot has stepped down from his review manager role, is there anyone else who would take that over? It's a little bit of a shame to have that code just lying around for so long.

On Sunday, 26 July 2015 at 09:09:51 UTC, Sönke Ludwig wrote:
> Am 07.04.2015 um 18:37 schrieb Sönke Ludwig:
>> Anyone up to this? The issues of the previous discussion [1] have all
>> been addressed now more or less, so the package is ready for a more
>> thorough review.
>>
>> Code: https://github.com/s-ludwig/std_data_json
>> Docs: http://s-ludwig.github.io/std_data_json/
>>
>> [1]:
>> http://forum.dlang.org/thread/lt5s76$is$1@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com
>>
>
> So, since Dicebot has stepped down from his review manager role, is there anyone else who would take that over? It's a little bit of a shame to have that code just lying around for so long.

I can do it. It's just announcing and counting votes, right? Is the formal review now?

Atila

Am 27.07.2015 um 22:00 schrieb Atila Neves:
> On Sunday, 26 July 2015 at 09:09:51 UTC, Sönke Ludwig wrote:
>> Am 07.04.2015 um 18:37 schrieb Sönke Ludwig:
>>> Anyone up to this? The issues of the previous discussion [1] have all
>>> been addressed now more or less, so the package is ready for a more
>>> thorough review.
>>>
>>> Code: https://github.com/s-ludwig/std_data_json
>>> Docs: http://s-ludwig.github.io/std_data_json/
>>>
>>> [1]:
>>> http://forum.dlang.org/thread/lt5s76$is$1@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com
>>>
>>>
>>
>> So, since Dicebot has stepped down from his review manager role, is
>> there anyone else who would take that over? It's a little bit of a
>> shame to have that code just lying around for so long.
>
> I can do it. It's just announcing and counting votes, right? Is the
> formal review now?
>
> Atila

That'd be great, thanks! I *think* that's all (maybe also updating the wiki) and since there is no other review going on, it should be possible to start a new one now. But I also don't know for sure...

On Monday, 27 July 2015 at 20:30:23 UTC, Sönke Ludwig wrote:
> Am 27.07.2015 um 22:00 schrieb Atila Neves:
>> On Sunday, 26 July 2015 at 09:09:51 UTC, Sönke Ludwig wrote:
>>> Am 07.04.2015 um 18:37 schrieb Sönke Ludwig:
>>>>[...]
>>>
>>> So, since Dicebot has stepped down from his review manager role, is
>>> there anyone else who would take that over? It's a little bit of a
>>> shame to have that code just lying around for so long.
>>
>> I can do it. It's just announcing and counting votes, right? Is the
>> formal review now?
>>
>> Atila
>
> That'd be great, thanks! I *think* that's all (maybe also updating the wiki) and since there is no other review going on, it should be possible to start a new one now. But I also don't know for sure...

I guess folks would be much more willing to do this if it was defined somewhere what it exactly means ;)

--Stephan

Am 28.07.2015 um 10:38 schrieb extrawurst:
> On Monday, 27 July 2015 at 20:30:23 UTC, Sönke Ludwig wrote:
>> (...)
>> That'd be great, thanks! I *think* that's all (maybe also updating the
>> wiki) and since there is no other review going on, it should be
>> possible to start a new one now. But I also don't know for sure...
>
> I guess folks would be much more willing to do this if it was defined
> somewhere what it exactly means ;)
>
> --Stephan

Just found something:
http://wiki.dlang.org/Review/Process#Review_Manager

On Wednesday, 8 April 2015 at 10:02:30 UTC, Sönke Ludwig wrote:
> Am 08.04.2015 um 10:24 schrieb Andrea Fontana:
>> Any plan to support functions like these?
>>
>> http://forum.dlang.org/thread/lrknjl$co7$1@digitalmars.com?page=4#post-bcszdbasnjzmbwzdgeqy:40forum.dlang.org
>
> There is opt() [1], which takes a path and returns a `Nullable!JSONValue`. "get" is unfortunately already taken by std.typecons.Algebraic, so we can't use it for its AA meaning.
>
> Maybe another overload of opt?
> JSONValue opt(JSONValue default_value, string[] path...);
>
> [1]: http://s-ludwig.github.io/std_data_json/stdx/data/json/value/json_value.opt.html

This seems a bit awkward to use. For example, it cannot handle numeric indices. Could we instead have an `undefined` value, that evaluates to `false` in a boolean context, and otherwise behaves as if it were absent? The two `opIndex` overloads will again return `undefined` for this value, as well as for non-objects and non-arrays, and for non-existing elements. Then you could access JSON values in an intuitive way without worrying about getting Exceptions or even Errors:

    writeln(json[42]["abc"][10 .. 20].get!int);

Only the `get` operation would throw if the type is wrong.

This also allows for easy and unambiguous testing whether an object contains a key:

    if(json["bla"] == JSONValue.undefined) { writeln("not found"); }

Anyway, it needs to be made clear what the behaviour on out-of-bounds or non-existing keys is: `undefined` value, exception, error?

On 2015-07-28 11:23, Sönke Ludwig wrote:

> Just found something:
> http://wiki.dlang.org/Review/Process#Review_Manager

I would add "making sure the review queue is updated".

-- 
/Jacob Carlborg