www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Shall I use std.json at my own risks ?

reply "jean christophe" <cybrarian live.fr> writes:
Hello

would you guys say that std.json is a good or bad choice dor a 
desktop application ? I've read many threads about it on the 
forum and finally I don't realy know what to do Oo`

I need my Gtkd application to maintain a (possibly big) archive 
database of financial records downloaded daily from the server 
application. In my case JSON seems to be the most convenient 
format. Please let me know if, according to you, std.json will 
cast aside as std.xml.

Thenks.

PS: As I'm new to the forum, I'd like to thank the D core 
community for such a GREAT language. I shall admit that it was 
difficult to abandon Emacs :s Anyway I've not been so positively 
impressed by a new language since Java 0.
Nov 12 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 13, 2013 06:26:53 jean christophe wrote:

 Hello
 
 would you guys say that std.json is a good or bad choice dor a
 desktop application ? I've read many threads about it on the
 forum and finally I don't realy know what to do Oo`
 
 I need my Gtkd application to maintain a (possibly big) archive
 database of financial records downloaded daily from the server
 application. In my case JSON seems to be the most convenient
 format. Please let me know if, according to you, std.json will
 cast aside as std.xml.
 
 Thenks.
 
 PS: As I'm new to the forum, I'd like to thank the D core
 community for such a GREAT language. I shall admit that it was
 difficult to abandon Emacs :s Anyway I've not been so positively
 impressed by a new language since Java 0.


I expect that std.json will be replaced at some point. There's certainly been 
talk of it from time to time, and I don't think that it's range-based like it 
should be. However, as I understand it, it's not in as bad shape as std.xml 
is. So, it's more reasonable to use. As I understand it, std.xml should 
probably just be avoided unless your desperate.

vibe.d also appears to have a json parser, so you may want to look at that as 
well:

http://vibed.org/api/vibe.data.json/

- Jonathan M Davis
Nov 12 2013
prev sibling next sibling parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Wednesday, 13 November 2013 at 05:26:54 UTC, jean christophe
wrote:

 Hello

 would you guys say that std.json is a good or bad choice dor a 
 desktop application ? I've read many threads about it on the 
 forum and finally I don't realy know what to do Oo`

 I need my Gtkd application to maintain a (possibly big) archive 
 database of financial records downloaded daily from the server 
 application. In my case JSON seems to be the most convenient 
 format. Please let me know if, according to you, std.json will 
 cast aside as std.xml.

 Thenks.

 PS: As I'm new to the forum, I'd like to thank the D core 
 community for such a GREAT language. I shall admit that it was 
 difficult to abandon Emacs :s Anyway I've not been so 
 positively impressed by a new language since Java 0.


I have fiddled with std.json and it seems OK, but lacks
documentation and has fairly limited functionality.  If you don't
mind creating another dependency you can try Vibe.D's json tools,
they are fantastic.

Craig
Nov 12 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 13, 2013 at 07:00:43AM +0100, Craig Dillabaugh wrote:

 On Wednesday, 13 November 2013 at 05:26:54 UTC, jean christophe
 wrote:

Hello

would you guys say that std.json is a good or bad choice dor a
desktop application ? I've read many threads about it on the forum
and finally I don't realy know what to do Oo`

I need my Gtkd application to maintain a (possibly big) archive
database of financial records downloaded daily from the server
application. In my case JSON seems to be the most convenient
format. Please let me know if, according to you, std.json will
cast aside as std.xml.

Thenks.

PS: As I'm new to the forum, I'd like to thank the D core
community for such a GREAT language. I shall admit that it was
difficult to abandon Emacs :s Anyway I've not been so positively
impressed by a new language since Java 0.


 
 I have fiddled with std.json and it seems OK, but lacks
 documentation and has fairly limited functionality.  If you don't
 mind creating another dependency you can try Vibe.D's json tools,
 they are fantastic.


[...]

What's the reason vibe.d's json tools aren't backported to Phobos?


T

-- 
Public parking: euphemism for paid parking. -- Flora
Nov 12 2013
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 13 November 2013 at 06:13:08 UTC, H. S. Teoh wrote:

 What's the reason vibe.d's json tools aren't backported to 
 Phobos?


It is quite a lot of effort to adjust module to match Phobos 
guidelines and push it through the review. No one has been 
motivated enough to do this for stuff that "already works".
Nov 13 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, November 12, 2013 22:11:45 H. S. Teoh wrote:

 What's the reason vibe.d's json tools aren't backported to Phobos?


Probably because no one has ever bothered to try and get them ready to be 
reviewed for inclusion in Phobos. Also, vibe.d seems to have a lot of 
interdependencies with itself, making it so that some parts of it couldn't be 
put into Phobos very easily. I don't know how much of that affects their json 
module though, since I would have thought that that would be the sort of thing 
which would be fairly standalone.

- Jonathan M Davis
Nov 12 2013
parent "Nicolas Sicard" <dransic gmail.com> writes:
On Wednesday, 13 November 2013 at 06:30:21 UTC, Jonathan M Davis 
wrote:

 On Tuesday, November 12, 2013 22:11:45 H. S. Teoh wrote:

 What's the reason vibe.d's json tools aren't backported to 
 Phobos?


 Probably because no one has ever bothered to try and get them 
 ready to be
 reviewed for inclusion in Phobos. Also, vibe.d seems to have a 
 lot of
 interdependencies with itself, making it so that some parts of 
 it couldn't be
 put into Phobos very easily. I don't know how much of that 
 affects their json
 module though, since I would have thought that that would be 
 the sort of thing
 which would be fairly standalone.

 - Jonathan M Davis


Actually, vibe.d's Json module was nearly independent from the 
rest of the framework, I mean until recently (I don't know if it 
is any more). It could be extracted in no time. But it seems that 
the main reason for not backporting it to Phobos was the need to 
wait for std.serialization.
Nov 12 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Wednesday, 13 November 2013 at 05:26:54 UTC, jean christophe 
wrote:

 Hello

 would you guys say that std.json is a good or bad choice dor a 
 desktop application ? I've read many threads about it on the 
 forum and finally I don't realy know what to do Oo`

 I need my Gtkd application to maintain a (possibly big) archive 
 database of financial records downloaded daily from the server 
 application. In my case JSON seems to be the most convenient 
 format. Please let me know if, according to you, std.json will 
 cast aside as std.xml.

 Thenks.

 PS: As I'm new to the forum, I'd like to thank the D core 
 community for such a GREAT language. I shall admit that it was 
 difficult to abandon Emacs :s Anyway I've not been so 
 positively impressed by a new language since Java 0.


I've been using it std.json extensively. I don't really like it 
because traversing the structure is not so fun, but it's very 
fast and has been very reliable.

Whether or not json is the right choice for your application is 
something only you can decide. I know for example that json is a 
poor choice for human readable things such as configuration files 
because the format is ugly and comments are not allowed, also if 
your application must preserve order among fields, forget about 
json, order is only preserved among array elements.

json also suffers from data typing issues because the type must 
be inferred from the supplied data. For the most part it's OK, 
but care must be taken to ensure the right conversions will take 
place, for example if you want the number 1 to be seen as a real 
number, it must be specified as 1.0.

Finally, json is a subset of java script, and if you are 
interfacing with a JS application, it turns out that JS has no 
integer types, only real types which are of a lower resolution 
than what D can provide, this means that you have to take care 
not to overflow integers past a maximum value where precision is 
lost. You will not get an error, instead your numbers will lose 
some of their less significant digits - it's an insidious problem 
if not dealt with at the source ends.

I guess that I'm saying is that while std.json is rock solid and 
very fast, you may want to consider better alternatives to the 
json format unless there's a technical reason why json must be 
used.

Have fun :)

--rt
Nov 12 2013
parent "jean christophe" <cybrarian live.fr> writes:
On Wednesday, 13 November 2013 at 06:16:07 UTC, Rob T wrote:


 I need my Gtkd application to maintain a (possibly big) 
 archive database of financial records downloaded daily from 
 the server application. In my case JSON seems to be the most 
 convenient format. Please let me know if, according to you, 
 std.json will cast aside as std.xml.




...


 I guess that I'm saying is that while std.json is rock solid 
 and very fast, you may want to consider better alternatives to 
 the json format unless there's a technical reason why json must 
 be used.

 Have fun :)

 --rt


Well first thank you for sharing your experiences.

You mentioned that a) std.json is solid and fast and b) it's not 
due to be deprecated. You've really helped me to make my choice. 
I'm going to use that module. It'd be easier to implement the 
retrieval of data from the server application side which is 
written in PHP. For example, a simple 
`json_encode($bigDataObject)` would be fair enough to send data 
to the desktop application.

I agree that the API std.json is not sexy. But if it is reputed 
solid and fast, why just not keep it, gently fix possible bugs, 
and for those who need more fancy access to the JSON data, wrap 
it in some kind of std.json.helper or similar extension. Jonathan 
mentioned above that it is not range-based which is a lack as 
ranges are one of the paradigms of D. IMO, it's important to have 
a stable standard library onto which one can build real 
applications programs in D. Too much forking is bad.

BTW I've tested the use of std.json with import std.parallelism 
and it works. It's a pretty good news. The example below is 
borrowed from Ali.

import std.stdio;
import std.json;
import std.conv;
import std.file;
import std.random;
import std.parallelism;
import core.thread;

struct Employee
{
   int id;
   string firstName;
   string lastName;

   void initStuf(JSONValue employeeJson)
   {
     writefln("Start long task for Employee %s", id);
     JSONValue[string] employee = employeeJson.object;		
     firstName = employee["firstName"].str;
     lastName  = employee["lastName"].str;
     Thread.sleep(uniform(1, 3).seconds); // Wait for a while
     writefln("Done long task for Employee %s", id);
   }
}

void main()
{
   auto content =
     `{"employees": [
        { "firstName":"John" ,   "lastName":"Doe"},
        { "firstName":"Anna" ,   "lastName":"Smith"},
        { "firstName":"Peter" ,  "lastName":"Jones"},
        { "firstName":"Kim" ,    "lastName":"Karne"},
        { "firstName":"Yngwee" , "lastName":"Malmsteen"},
        { "firstName":"Pablo" ,  "lastName":"Moses"}		  ]
       }`;

   JSONValue[string] document = parseJSON(content).object;
   JSONValue[] employees = document["employees"].array;
   uint employeeId = 0;

   foreach (employeeJson; parallel(employees))
     {
       auto e = Employee( employeeId++ );
       e.initStuf( employeeJson );
     }
}

Gives :

Start long task for Employee 0
Start long task for Employee 4
Start long task for Employee 5
Start long task for Employee 1
Start long task for Employee 3
Start long task for Employee 2
Done long task for Employee 4
Done long task for Employee 5
Done long task for Employee 1
Done long task for Employee 3
Done long task for Employee 0
Done long task for Employee 2
Nov 13 2013
prev sibling next sibling parent "growler" <growlercab gmail.com> writes:
On Wednesday, 13 November 2013 at 05:26:54 UTC, jean christophe 
wrote:

 Hello

 would you guys say that std.json is a good or bad choice dor a 
 desktop application ? I've read many threads about it on the 
 forum and finally I don't realy know what to do Oo`

 I need my Gtkd application to maintain a (possibly big) archive 
 database of financial records downloaded daily from the server 
 application. In my case JSON seems to be the most convenient 
 format. Please let me know if, according to you, std.json will 
 cast aside as std.xml.

 Thenks.

 PS: As I'm new to the forum, I'd like to thank the D core 
 community for such a GREAT language. I shall admit that it was 
 difficult to abandon Emacs :s Anyway I've not been so 
 positively impressed by a new language since Java 0.


I was using std.json exclusively for serialisation of D classes, 
SQL tables into D structs and D structs into GtkD (GUI) trees.

It was fine and fast enough for my needs.

I have now switched to vibe.d Json and removed the dependencies 
it had. From memory it only depends on isRWPlaneField and 
isRWField in vibed/src/data/utils.d, I just ripped these out and 
stuck them in the json.d file.

Vibe's Json has a nicer interface and better type checking.
Nov 13 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
std.json is ok. If you want a prettier api btw, I wrote a module 
called jsvar that uses it to provide a D type that is very 
similar to a javascript var:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/jsvar.d

void main() {
	import arsd.jsvar;
	
	auto some_json = `{"foo":"bar","number":20}`;
	var a = var.fromJson(some_json);

	assert(a.foo == "bar"); // works for easy access
	assert(a.number == 20);

	a.number += 15; // you can modify it too

	import std.stdio;
	writeln(a.number); // 35
}

If you want the specific type, there's a.payloadType == 
var.Type.Integral and so on. Then you can do int b = a.get!int; 
(you can actually do that even if a is a string, it will try to 
convert for you)


I think std.json's core is usable, just the interface isn't as 
beautiful as it could be in D. My jsvar tries to close that gap.
Nov 13 2013