Ticket #212 (closed defect: invalid)

Opened 2 years ago

Last modified 1 year 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 2 years 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 2 years 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 2 years 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 2 years 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 2 years ago by lth

Consensus:

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

Changed 1 year ago by David-Sarah Hopwood

  • status changed from new to closed
  • resolution set to invalid

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

Note: See TracTickets for help on using tickets.