On Thursday, 24 July 2014 at 18:49:27 UTC, Ary Borenszweig wrote:
> On 7/24/14, 1:58 PM, Justin Whear wrote:
>> On Thu, 24 Jul 2014 13:49:27 -0300, Ary Borenszweig wrote:
>>
>>> Nope, a JSON can only be an array or an object (hash).
>>
>> Ary, can you point out the place in the spec where this is specified?
>> Not to be pedantic, but the spec only seems to define a "JSON value", not
>> a "JSON document".
>>
>
> You are right, my bad. According to Wikipedia (which has links to RFCs):
>
> Early versions of JSON (such as specified by RFC 4627) required that a valid JSON "document" must consist of only an object or an array type—though they could contain other types within them. This restriction was relaxed starting with RFC 7158, so that a JSON document may consist entirely of any possible JSON typed value.

Sorry, Justin Whear, you were right, I was wrong. Yep, now it's pretty clear why there is JSONValue.

On Thursday, 24 July 2014 at 16:09:25 UTC, Justin Whear wrote:
> On Thu, 24 Jul 2014 16:04:01 +0000, Pavel wrote:
>> 
>> Thanks to all you folks who explained "in" operator for me. My bad.
>> Let's focus on the real problem, which is JSON wrapper class. Is it
>> needed? Wouldn't it be better to get AA from parseJSON?
>
> The following are valid JSON:
>
> auto json1 = parseJSON(`1`);
> auto json2 = parseJSON(`"foo"`);
> auto json3 = parseJSON(`[1, 2, 3]`);
>
> None of these fit naturally into an JSONValue[string] return type.

Now we figured it out about JSON, but in that case:
Why not just use std.variant.Variant construct instead of JSONValue?

On Thu, 24 Jul 2014 22:00:43 +0000, Pavel wrote:

> On Thursday, 24 July 2014 at 16:09:25 UTC, Justin Whear wrote:
>> On Thu, 24 Jul 2014 16:04:01 +0000, Pavel wrote:
>>> 
>>> Thanks to all you folks who explained "in" operator for me. My bad. Let's focus on the real problem, which is JSON wrapper class. Is it needed? Wouldn't it be better to get AA from parseJSON?
>>
>> The following are valid JSON:
>>
>> auto json1 = parseJSON(`1`);
>> auto json2 = parseJSON(`"foo"`);
>> auto json3 = parseJSON(`[1, 2, 3]`);
>>
>> None of these fit naturally into an JSONValue[string] return type.
> 
> Now we figured it out about JSON, but in that case:
> Why not just use std.variant.Variant construct instead of JSONValue?

While I suspect the reason is simply historical, it might be a type- safety/information problem as well.  Variant can store values of essentially any type whereas JSON is strictly limited to a handful of simple types.  Going from a JSON string to Variant might not be troublesome, but going from Variant to JSON string almost certainly would.

That said, if you think it's worth it, I'd be up for reviewing a revamped std.json.

On 7/25/14, 1:06 PM, Justin Whear wrote:
> On Thu, 24 Jul 2014 22:00:43 +0000, Pavel wrote:
>
>> On Thursday, 24 July 2014 at 16:09:25 UTC, Justin Whear wrote:
>>> On Thu, 24 Jul 2014 16:04:01 +0000, Pavel wrote:
>>>>
>>>> Thanks to all you folks who explained "in" operator for me. My bad.
>>>> Let's focus on the real problem, which is JSON wrapper class. Is it
>>>> needed? Wouldn't it be better to get AA from parseJSON?
>>>
>>> The following are valid JSON:
>>>
>>> auto json1 = parseJSON(`1`);
>>> auto json2 = parseJSON(`"foo"`);
>>> auto json3 = parseJSON(`[1, 2, 3]`);
>>>
>>> None of these fit naturally into an JSONValue[string] return type.
>>
>> Now we figured it out about JSON, but in that case:
>> Why not just use std.variant.Variant construct instead of JSONValue?
>
> While I suspect the reason is simply historical, it might be a type-
> safety/information problem as well.  Variant can store values of
> essentially any type whereas JSON is strictly limited to a handful of
> simple types.  Going from a JSON string to Variant might not be
> troublesome, but going from Variant to JSON string almost certainly would.
>
> That said, if you think it's worth it, I'd be up for reviewing a revamped
> std.json.

Or use Algebraic, but it currently doesn't support recursive type definitions.

I think this would be the best way.

On Saturday, 26 July 2014 at 00:26:08 UTC, Ary Borenszweig wrote:
> Or use Algebraic, but it currently doesn't support recursive type definitions.

Algebraic does support recursive type definitions.

import std.variant;

alias Rec = Algebraic!(int, This*);

void main()
{
    //I'm not sure why this works
    auto i = Rec(Rec(Rec(1)));

    i = Rec(new Rec(new Rec(1)));
}

AFAIK, Variant is not transparent. You can't write parsed["field1"]["field2"], it should be parsed["field1"].get!(Variant[string])["field2"].

On Thursday, 24 July 2014 at 16:09:25 UTC, Justin Whear wrote:
> On Thu, 24 Jul 2014 16:04:01 +0000, Pavel wrote:
>> 
>> Thanks to all you folks who explained "in" operator for me. My bad.
>> Let's focus on the real problem, which is JSON wrapper class. Is it
>> needed? Wouldn't it be better to get AA from parseJSON?
>
> The following are valid JSON:
>
> auto json1 = parseJSON(`1`);
> auto json2 = parseJSON(`"foo"`);
> auto json3 = parseJSON(`[1, 2, 3]`);
>
> None of these fit naturally into an JSONValue[string] return type.

auto json4 = parseJSON(`true`);
This is a valid JSON also.

I know that as per JSON spec there's no boolean type specified, only separate true and false values, which are specified as type in http://dlang.org/library/std/json/JSON_TYPE.html, so I guess the only way to check boolean in JSONValue it is to write:

if (json4.type == JSON_TYPE.True) {
} else {
}

Am I right?

On Fri, 08 Aug 2014 14:07:33 +0000, Pavel wrote:

> 
> I know that as per JSON spec there's no boolean type specified, only separate true and false values, which are specified as type in http://dlang.org/library/std/json/JSON_TYPE.html, so I guess the only way to check boolean in JSONValue it is to write:
> 
> if (json4.type == JSON_TYPE.True) {
> } else {
> }
> 
> Am I right?

That's right.  Perhaps we need an `asBool` function or even an opCast!bool that returns false on FALSE, NULL, and possibly empty strings/ objects/arrays.