JSON.parse should be simple and idiot-proof
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>
>> 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" , from web-integration perspective.
>>> 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.
>>>  stage-1 proposal - JSON.parse source text access
>>> kai zhu
>>> kaizhu256 at gmail.com
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss