Ticket #212 (new defect)

Opened 10 months ago

Last modified 9 months ago

Builtins: Remove JSON

Reported by: lth Assigned to: anonymous
Type: defect Priority: major
Milestone: Component: Proposals
Version: 4 Keywords:
Cc:

Description

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.

Attachments

Change History

Changed 10 months ago by 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.

Changed 10 months ago by 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.

Changed 9 months ago by lth

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

Changed 9 months ago by lth

  • summary changed from Bultins: Remove JSON to Builtins: Remove JSON

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

Changed 9 months ago by lth

Consensus:

  • We remove the current json proposal
  • We leave a placeholder for a JSON object, TBD at later date
Note: See TracTickets for help on using tickets.