On Sun, 24 Oct 2010 00:30:42 -0400, Andrei Alexandrescu
<[email protected]> wrote:
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;
Unfortunately, This[string] currently causes an ICE. There's some
documentation in Variant that self referential types are not yet
supported. Also, I've found that using opDispatch to mimic fields, i.e.
foo.bar instead of foo["bar"], to be quite convenient. Would this be a
good feature candidate for inclusion in VariantN? Also, I'm not up to date
regarding VariantN bugs. Are they things you can work around, or are they
blocked by compiler issues?
* 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.
My parser takes an input range by ref.
* toJSON returns a string, which is inefficient for large objects. It
should take an output range.
My writer takes an output range by ref. I have a compact writer, a pretty
print writer and a toJsonString convenience function.
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
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
