I strongly believe std.json must be replaced. Here is my list of
grievances and requirements:
* JSONValue is utterly unsafe because it relies on an open tagged union.
Essentially memory safety is entirely dependent on the user.
* Even if the union were made safe, handling things with an enum is
antiquated. The code should use types throughout, a la Algebraic, or -
better yet - use Algebraic itself:
struct JSONFalse {};
struct JSONTrue {};
struct JSONNull {};
alias Algebraic!(
string,
long,
This[string],
This[],
JSONTrue,
JSONFalse,
JSONNull
) JSONValue;
* The function parseJSON takes a range but not by reference, which means
there is no way for the caller to know the new range position after
having parsed one json object.
* toJSON returns a string, which is inefficient for large objects. It
should take an output range.
Even if we later add serialization based on json transport, a simple,
independent API would be beneficial for many. I'm thinking in fact of
adding support for Json in std.format by means of %j. So then you can
read and write Json stuff with writef and readf.
Andrei
On 10/23/10 20:09 CDT, Robert Jacques wrote:
On Sat, 23 Oct 2010 20:14:14 -0400, Brian Schott
<[email protected]> wrote:
What are the plans for this module? The last I heard, there were plans
for removing it or rewriting it,and nobody knew why it was included in
Phobos in the first place.
The documentation
(http://www.digitalmars.com/d/2.0/phobos/std_json.html) makes no mention
of this. If this is scheduled for removal (or a rewrite), can the
documentation please make a note of this? (Even something simple like
the comment in std.contracts would be sufficient to warn people)
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
I'd also like to know the plans for this module. I've commented before
that the implementation is both buggy and non-complaint. I have an my
own JSON implementation that I've just started to clean up to Phobos
quality. I'm been holding off on cleaning it up mainly because I need it
for serialization/de-serialization and I don't want to add a naive JSON
serialization routine, just to have std.serialization(?) deprecate it.
Also, Sean commented he'd like to have a SAX style JSON parser, which is
something I don't have yet.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
