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
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
> kaizhu256 at gmail.com <mailto:kaizhu256 at gmail.com>
>
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
On 2018-10-21 08:01, kai zhu wrote:
Be happy, now you have not less than TWO proposals for extending the ES6 JSON object! :-)
A [potentially biased] comparison between gibson042/ecma262-proposal-JSON-parse-with-source and cyberphone/es6-bigint-json-support#21-the-jsonnumber-primitive:
The introduction of a JSONNumber type in the latter proposal:
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