He was recommending a single parameter for "parse ints as bigints", not changing the default behavior.
On Sun, Oct 21, 2018, 09:58 Richard Gibson <[email protected]> wrote: > First, note that reviver functions *do* manipulate the result after it's > parsed. Second, "parse ints as bigints" is too big a hammer—changing the > output for all numbers would break currently working code. And third, it's > not even fully sufficient for the "big numbers" purpose, which logically > also includes non-integers outside the IEEE 754 64-bit range ("BigFloat"). > > On Sun, Oct 21, 2018 at 10:50 AM Isiah Meadows <[email protected]> > wrote: > >> Just because something exists doesn't mean it'll be broadly used. Plus, >> reviver functions are normally incredibly simple - you don't get enough >> context (like key paths) to do anything crazy, and this proposal doesn't >> give you enough context for that. >> >> In practice, this changes literally nothing for most consumers, since the >> use case is incredibly limited and usually requires server agreement as >> well. In fact, that's where my skepticism lies: why add 3 new reviver >> parameters when a single "parse ints as bigints" would solve basically the >> entire problem? I've yet to see any other use case that couldn't be solved >> by manipulating the result after it's parsed. >> >> But personally, I don't see how bugs would be a major issue here >> considering its limited utility. >> >> On Sun, Oct 21, 2018 at 02:01 kai zhu <[email protected]> wrote: >> >>> wish to express skepticism for the stage-1 proposal "JSON.parse source >>> text access" [1], from web-integration perspective. >>> >>> 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 >>> [email protected] >>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
