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
parent reply "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
next sibling parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
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
prev 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