[phobos] Plans for std.json

[Robert Jacques]

On Sun, 24 Oct 2010 00:30:42 -0400, Andrei Alexandrescu  
<andrei at erdani.com> 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
>> <briancschott at gmail.com> 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
>>> phobos at puremagic.com
>>> 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
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos