On 2018-10-21 08:01, kai zhu wrote:
wish to express skepticism for the stage-1 proposal "JSON.parse source text access" [1], from web-integration perspective.
Be happy, now you have not less than TWO proposals for extending the ES6 JSON object! :-) A [potentially biased] comparison between https://github.com/gibson042/ecma262-proposal-JSON-parse-with-source and https://github.com/cyberphone/es6-bigint-json-support#21-the-jsonnumber-primitive: The introduction of a JSONNumber type in the latter proposal: - only requires an optional extra boolean flag to JSON.parse() - also works in the other direction, JSON.stringify(). Without changing the API - is compatible both with "stream parsing" using the reviver function as well as the more commonly used "see what you got after parsing" method - addresses the only real short-coming of the ES6 JSON object, namely JSON number handling It is also worth keeping in mind that the JSON world is slowly drifting towards "schemas" making the ES6 JSON object less interesting. Although I indeed wrote a specification for dealing with with JSON numbers outside of IEEE double precision, I still claim that the advantages of using the RFC mode is ZERO, and in fact introduces new problems like forcing stream/schema parsing or introducing "super types" like my JSONNumber. "Fulfilling RFCs" is not something application programmers are particularly concerned with. Expressing "big":5656565656565656565 as "big":"5656565656565656565" is simply put not a big deal. The way this is currently implemented in for example JDK is anyway incompatible with just about everything else out there :-) Anders
a common javascript-painpoint is pinpointing bug-source of end-to-end client<->server communications. thankfully, JSON.parse is rarely suspect in this process. this proposal however, encourage developers to introduce bugs/doubts-of-reliability to JSON.parse, making integration bug-hunting more painful than it already is. standard-operating-procedure for reviving JSON-data is a 2-step process: 1. JSON.parse with zero-config to rule-out bugs during this step 2. second-pass of plain-JSON to revive [product-specific] string-encoded non-JSON datatypes like BigInt/Date/RegExp, where bugs can be expected you normally do not want to complicate bug-hunts by contaminating step-1 with bugs from step-2. [1] stage-1 proposal - JSON.parse source text access https://github.com/gibson042/ecma262-proposal-JSON-parse-with-source kai zhu kaizhu...@gmail.com <mailto:kaizhu...@gmail.com> _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
