JSON.parse should be simple and idiot-proof

Isiah Meadows isiahmeadows at gmail.com
Sun Oct 21 17:00:15 UTC 2018


This would be the correct understanding here, a 4th parameter read as a
boolean.

On Sun, Oct 21, 2018 at 12:27 Peter Jaszkowiak <p.jaszkow at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/2b264c0f/attachment-0001.html>


More information about the es-discuss mailing list