std.json API improvement - Request for code review

Robert Jacques sandford at jhu.edu
Sun Sep 12 23:25:18 PDT 2010


On Mon, 13 Sep 2010 00:18:40 -0400, Brian Schott <brian-schott at cox.net>  
wrote:
> I just found the phobos mailing list. Why is it on a completely
> different server?

No clue. I've only just joined the list recently myself.

> Regarding the bugs, my intent was just to improve the usefulness of the
> existing implementation. I was not aware of any plans to drop this
> module. (There's no notice to this effect in the documentation the way
> there is with std.contracts)

There's no plan that I know of regarding std.json. The code was literally  
taken from a pastebin by Jeremie Pelletier and hasn't been touched (or  
discussed) since. It was lurking around with its documentation unlinked,  
like std.perf, but it appears that this is no longer the case (though this  
wasn't mentioned in the change logs). However, there has been a bunch of  
talk regarding serialization and so std.json will need to change to  
accommodate this. And Json value is really a specialized version of  
variant, so if certain bugs/etc where fixed in variant there'll be no need  
for json value.

> What do you recommend for dealing with JSON files until this is sorted  
> out?

There are two solutions, as I see it:
1) Move std.json (or an improved version) to user code land (i.e.  
scrapple) in the short term for people who need it. Long term, fix/improve  
std.variant and add a "std.serialize" module, probably based on orange.
2) Fix/improve std.json and decide later what to do with it when  
"std.serialize" arrives.

I've got my own Json library that I'm willing to share, but I need some  
basic serialization support and I know my compile-time only solution isn't  
going to be the final solution for phobos, so I've been reluctant to  
submit it as a replacement.


More information about the Digitalmars-d mailing list