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
