Builtins: Remove JSON

[lth]

Lars and Jeff propose that we remove JSON support.

The reasons are:

• JSON encoding and decoding are easily and efficiently written in ES4 (with the use of the new Map type circularity checking is efficient)
• There are diverging opinions in the community about how encoding and decoding should be done (toJSONString vs toJSON in the encoder; the type of filtering that can be done in the decoder). This will probably mean many users will load their own JSON libraries anyway, reducing the benefit of a standard implementation.
• It appears that instances of user-defined classes won't be serialized by JSON even if they are pure data containers. However, such instances would be serialized if they were created by ES3-style constructor functions. This forces users into staying with ES3-style data even when ES4-style data would be more appropriate.
• The fact that data that can't be encoded are silently ignored or defaulted to incompatible values (as when NaN becomes null), without any control being given to the program, is a weakness in the current design
• ES4 has facilities in the isPropertyEnumerable method to place DontEnum methods on objects, so libraries can safely be loaded by user code.

[graydon]

Agreed. I'm happier to leave larger parts of standard library building to the community now that we've handled the inclusion of a standard module system and a couple parametric standard containers. These will carry library authors a long way.

[lth]

After talking to Doug it seems to be the case that eg class Point would in fact be serialized -- anything whose "typeof" is "object" is the idea.

[lth]

Conclusion at September 2007 f2f was that Lars and Doug will try to work out an API that we can agree on.

[lth]

I have had a round of discussion with JSON stakeholders in TG1 and from es4-discuss. The transcripts are available on request, but the conclusions were:

• If we keep JSON, we should not keep the current proposal, but switch to a standalone JSON object with encoding/decoding methods, a la Doug's recent "json2" proposal
• The only argument in favor of keeping JSON in the language is performance, since several people believe that an eval-based implementation is unsafe and any other implementation in ES will be too slow.

My recommendations to TG1 are:

• We remove JSON from ES4.
• If a champion later comes forward with a new JSON proposal that represents a compromise among those committee members that care, then I think we should consider taking it back in. (I will not take on this role.)

[lth]

Consensus:

• We remove the current json proposal
• We leave a placeholder for a JSON object, TBD at later date

[David-Sarah Hopwood]

With JSON being included in ES3.1, this is now presumably invalid.