When I was using 2.064.2, I had a piece of code as below:

json.integer = T;
json.type = ((T == true) ? std.json.JSON_TYPE.TRUE : std.json.JSON_TYPE.FALSE);


After installing 2.065, the line I am setting the json type is not valid any more. The weird thing is that there is not specific `bool` method for JSONValue at all. At least for setting the value. Yes, I maybe can write as json.integer( true ) now, but that is not nice way to do this I think. Is there any reason not to add `bool` method into `std.json.JSONValue`?

The opAssign overload handles things sanely.

So use

JSON_VALUE v;

v = true;

and so on instead of the properties when setting.

On Monday, 24 February 2014 at 18:14:23 UTC, Adam D. Ruppe wrote:
> The opAssign overload handles things sanely.
>
> So use
>
> JSON_VALUE v;
>
> v = true;
>
> and so on instead of the properties when setting.

Why does the JSON_TYPE enum have "TRUE" and "FALSE" to begin with? Shouldn't it just be a single "BOOLEAN" type with two values?

Is it just "historic", or is there an actual rationale to this?

On Monday, 24 February 2014 at 18:14:23 UTC, Adam D. Ruppe wrote:
> The opAssign overload handles things sanely.
>
> So use
>
> JSON_VALUE v;
>
> v = true;
>
> and so on instead of the properties when setting.

Yes, it provides this, but while providing a method for other types, ignoring `bool` is not nice for D I think.

@monarch_dodra I think this is because JSON doesn't consider 0 and non-zero as boolean values, and use `true` `false` keywords for this purpose.

On Monday, 24 February 2014 at 18:22:43 UTC, monarch_dodra wrote:
> Why does the JSON_TYPE enum have "TRUE" and "FALSE" to begin with? Shouldn't it just be a single "BOOLEAN" type with two values?

The json spec lists true, false, and null as distinct values:
http://www.json.org/


My guess is that since they are represented by javascript keywords (and come from the weakly-typed language), this makes the lexer and parser implementation match right up the JSON_TYPE thing.

so I don't really know, but the 1-1 correspondence with the keywords kinda makes sense to me.

On Monday, 24 February 2014 at 18:33:49 UTC, Adam D. Ruppe wrote:
> On Monday, 24 February 2014 at 18:22:43 UTC, monarch_dodra wrote:
>> Why does the JSON_TYPE enum have "TRUE" and "FALSE" to begin with? Shouldn't it just be a single "BOOLEAN" type with two values?
>
> The json spec lists true, false, and null as distinct values:
> http://www.json.org/
>
>
> My guess is that since they are represented by javascript keywords (and come from the weakly-typed language), this makes the lexer and parser implementation match right up the JSON_TYPE thing.
>
> so I don't really know, but the 1-1 correspondence with the keywords kinda makes sense to me.

typeof(false) === "boolean" in JavaScript. There is a boolean type in JavaScript. It really should just be "BOOLEAN" in std.json.

I don't mean to show off or anything dumb like that, but I haven't used std.json for a while after I wrote my own library, which I tweaked until it was as efficient as std.json at what it does and hopefully bug free. (I have many test cases, and anything I missed I'll add more cases for.)

https://github.com/w0rp/dson/blob/master/json.d

JSON x; // x.isNull
x = true; // opAssign is specified in addition to constructors
x = false; // x.type == JSON_TYPE.BOOLEAN or just x.isBool
x = 3; // x.isNumber
x = null; // x.isNull
x = jsonArray(); // x.isArray
x = jsonObject(); // x.isObject

It goes on like that. I think std.json should have similar behaviour, because things can be a lot easier.

On Monday, 24 February 2014 at 18:57:53 UTC, w0rp wrote:
> It really should just be "BOOLEAN" in std.json.

yeah, or at least the getter property, I agree with that.

> I don't mean to show off or anything dumb like that, but I haven't used std.json for a while after I wrote my own library,

Aye, my jsvar works similarly ( though it actually uses std.json for the toJSON and parseJSON functions).

On Monday, 24 February 2014 at 19:20:23 UTC, Adam D. Ruppe wrote:
> On Monday, 24 February 2014 at 18:57:53 UTC, w0rp wrote:
>> It really should just be "BOOLEAN" in std.json.
>
> yeah, or at least the getter property, I agree with that.
>
>> I don't mean to show off or anything dumb like that, but I haven't used std.json for a while after I wrote my own library,
>
> Aye, my jsvar works similarly ( though it actually uses std.json for the toJSON and parseJSON functions).

I gave up on std.json and switched to the JSON type in vibed which includes a nice prettyPrint as well. Not sure on the performance of it though, never tested (never been a problem either).

Cheers,
ed

On Monday, 24 February 2014 at 22:33:52 UTC, ed wrote:
> On Monday, 24 February 2014 at 19:20:23 UTC, Adam D. Ruppe wrote:
>> On Monday, 24 February 2014 at 18:57:53 UTC, w0rp wrote:
>>> It really should just be "BOOLEAN" in std.json.
>>
>> yeah, or at least the getter property, I agree with that.
>>
>>> I don't mean to show off or anything dumb like that, but I haven't used std.json for a while after I wrote my own library,
>>
>> Aye, my jsvar works similarly ( though it actually uses std.json for the toJSON and parseJSON functions).
>
> I gave up on std.json and switched to the JSON type in vibed which includes a nice prettyPrint as well. Not sure on the performance of it though, never tested (never been a problem either).
>
> Cheers,
> ed

vibe.d's JSON is pretty good. There are really two things I don't like about it.

1. It never throws when you try to get a type out of it, so you'll get float.nan for to!float if it's actually an array.
2. It has an "undefined" type, so it doesn't throw when you look for an index or key that isn't there, it uses the JavaScript behaviour.

Those kind of put me off enough to make me write my own.

On Tuesday, 25 February 2014 at 07:58:23 UTC, w0rp wrote:
> On Monday, 24 February 2014 at 22:33:52 UTC, ed wrote:
>> On Monday, 24 February 2014 at 19:20:23 UTC, Adam D. Ruppe wrote:
>>> On Monday, 24 February 2014 at 18:57:53 UTC, w0rp wrote:
>>>> It really should just be "BOOLEAN" in std.json.
>>>
>>> yeah, or at least the getter property, I agree with that.
>>>
>>>> I don't mean to show off or anything dumb like that, but I haven't used std.json for a while after I wrote my own library,
>>>
>>> Aye, my jsvar works similarly ( though it actually uses std.json for the toJSON and parseJSON functions).
>>
>> I gave up on std.json and switched to the JSON type in vibed which includes a nice prettyPrint as well. Not sure on the performance of it though, never tested (never been a problem either).
>>
>> Cheers,
>> ed
>
> vibe.d's JSON is pretty good. There are really two things I don't like about it.
>
> 1. It never throws when you try to get a type out of it, so you'll get float.nan for to!float if it's actually an array.
> 2. It has an "undefined" type, so it doesn't throw when you look for an index or key that isn't there, it uses the JavaScript behaviour.
>
> Those kind of put me off enough to make me write my own.

Actually that is exactly what I like about it! Performance of exceptions in D is very bad and right now I am trying to reduce using them wherever I can.