JSON.parse should be simple and idiot-proof

Richard Gibson richard.gibson at gmail.com
Sun Oct 21 15:58:31 UTC 2018


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 <isiahmeadows at gmail.com>
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 <kaizhu256 at gmail.com> 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
>> kaizhu256 at gmail.com
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20181021/6379819b/attachment-0001.html>


More information about the es-discuss mailing list