www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bool setter for std.json

reply "Tolga Cakiroglu" <tcak pcak.com> writes:
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`?
Feb 24 2014
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
The opAssign overload handles things sanely.

So use

JSON_VALUE v;

v = true;

and so on instead of the properties when setting.
Feb 24 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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?
Feb 24 2014
prev sibling next sibling parent "Tolga Cakiroglu" <tcak pcak.com> writes:
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.
Feb 24 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Feb 24 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
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.
Feb 24 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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).
Feb 24 2014
prev sibling next sibling parent "ed" <growlercab gmail.com> writes:
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
Feb 24 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
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.
Feb 24 2014
prev sibling next sibling parent "Stephan" <Stephan extrawurst.org> writes:
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.
Feb 25 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Tuesday, 25 February 2014 at 08:07:28 UTC, Stephan wrote:
 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.

The alternative is the "everything went better than expected" approach. I'd prefer to let programs break and performance suffer when something is wrong with them.
Feb 25 2014
prev sibling parent "ed" <growlercab gmail.com> writes:
On Tuesday, 25 February 2014 at 08:47:50 UTC, w0rp wrote:
 On Tuesday, 25 February 2014 at 08:07:28 UTC, Stephan wrote:
 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.

The alternative is the "everything went better than expected" approach. I'd prefer to let programs break and performance suffer when something is wrong with them.

I agree with this and have hacked onto vibed json to throw exceptions unless a custom a custom version(JsnoNoThrow) is provided. Cheers, ed
Feb 25 2014