JSON.parse should be simple and idiot-proof

Peter Jaszkowiak p.jaszkow at gmail.com
Sun Oct 21 16:26:56 UTC 2018


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 <richard.gibson at gmail.com> 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 <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
>>
> _______________________________________________
> 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/c91ac220/attachment.html>


More information about the es-discuss mailing list