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)

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.

On Sat, Oct 23, 2010 at 05:14:14PM -0700, Brian Schott 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.

I sorta like it... I use it in a lot of places in my work code. (along with a helper template to convert structs to json)

On Saturday 23 October 2010 17:14:14 Brian Schott 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

As I understand it, the current one is not considered to be up to snuff and that there is no maintainer for it, so the intention is to replace it with a new one. However, there is not currently any replacement for it, and I believe that the Phobos devs are busy with other stuff. So, what likely needs to happen is that someone needs to decide to champion std.json and write a new version of it for possible inclusion in Phobos. As it stands, I believe that the Phobos devs are just too busy with other things, so it's sitting in the TODO list without any real plan.

- Jonathan M Davis

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 <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

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

On 10/24/10 1:05 CDT, Robert Jacques wrote:
> 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?

Definitely that issue needs to be looked at. I think it's a compiler bug, but then I didn't try real hard to avoid it.

Building on Algebraic would save a lot of work, and any further improvements in Algebraic will help json too.

>> * 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.

Then you may want to submit your code for review.


Andrei

If there's a tokenizer around, writing a plain old recursive descent SAX style parser is pretty trivial. Heck, I'd be happy to check a json parser for compliance errors and such. I'm just in a weird position for submitting one written from scratch, for work reasons. I like the requirements outlined by andrei though.

Sent from my iPhone

On Oct 23, 2010, at 6:09 PM, "Robert Jacques" <sandford at jhu.edu> 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

The DMD 2.050 beta zip contains no mention of std.json being scheduled for eventual replacement. Is it really a good idea to have another release with this code included and no warning that it will eventually go away?

On 10/23/2010 09:30 PM, Andrei Alexandrescu 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;
>
> * 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

I agree that we should add a mention. Other opinions?

Andrei

On 10/28/10 2:14 CDT, Brian Schott wrote:
> The DMD 2.050 beta zip contains no mention of std.json being scheduled for eventual replacement. Is it really a good idea to have another release with this code included and no warning that it will eventually go away?
>
> On 10/23/2010 09:30 PM, Andrei Alexandrescu 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;
>>
>> * 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
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos