JSON.parse should be simple and idiot-proof

kai zhu kaizhu256 at gmail.com
Mon Oct 22 08:09:03 UTC 2018


i'm against all these proposals.  JSON.parse should remain zero-config and idiot-proof.  you will *always* need a second-pass in product-development to revive non-JSON datatypes anyways, like Date, and thats where reviving BigInt should take place as well.

again, i'm ok with working on web-projects where there are bugs in the second-pass (which is expected).  i'm not ok with web-projects, where i cannot reliably trust JSON.parse to do its job (and have to add it to checklist of things to inspect when figuring out where the bug is in end-to-end communications).

fyi, the twitter example is not compelling. it already has a string-form “id_str” which is more appropriate/easier-to-handle in javascript-land.  what benefit does a pseudorandom BigInt “id” (which has no need of arithmetic) have over plain-string “id_str” in javascript-land? none.

kai zhu
kaizhu256 at gmail.com

> On 22 Oct 2018, at 2:59 AM, Peter Jaszkowiak <p.jaszkow at gmail.com> wrote:
> 
> What if `JSON.parse` took an options object as the second parameter?
> There's already been an instance of a JS API changing from booleans to an options object: `addEventListener`.
> 
> I know it wasn't tc39, but it shows that it's possible. Another option is to add a different method to the `JSON` object.
> 
> On Sun, Oct 21, 2018, 13:45 Richard Gibson <richard.gibson at gmail.com <mailto:richard.gibson at gmail.com>> wrote:
> Yes, understood. And setting aside the undesirable characteristics of boolean trap <https://ariya.io/2011/08/hall-of-api-shame-boolean-trap> interfaces for the moment (which will certainly be a source of regret if ECMAScript ever gets a BigFloat), my point is that doing so would affect parsing of all numbers, as opposed to only those numbers that really should be BigInts. For example, let's look at a sample Twitter API entity <https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/tweet-object>:
> 
> {
>  "created_at":"Thu Apr 06 15:24:15 +0000 2017",
>  "id": 850006245121695744,
>  "id_str": "850006245121695744",
>  "text": "1/ Today we’re sharing our vision for the future of the Twitter API platform!nhttps://t.co/XweGngmxlP <http://t.co/XweGngmxlP>",
>  "user": {
>   "id": 6253282,
>   "id_str": "6253282",
>   "name": "Twitter API",
>   "screen_name": "twitterapi",
>   "followers_count": 21,
>   "friends_count": 32
>  },  
>  "entities": {}
> }
> 
> It's nice that e.g. JSON.parse(…, null, true) would allow us to access the ids as full-fidelity numbers (Twitter documents them as an int64), but much less nice that the behavior would affect all numbers. For instance, let's say this is one tweet in a list that we want to sort by the "follower ratio" of their creators:
> 
> let creatorPopularity = tweet.user.followers_count / tweet.user.friends_count;
> // (without parse-as-BigInt) → 0.65625
> // (with parse-as-BigInt)    → 0n
> 
> We just silently lost floating-point arithmetic.
> 
> On Sun, Oct 21, 2018 at 1:00 PM Isiah Meadows <isiahmeadows at gmail.com <mailto:isiahmeadows at gmail.com>> wrote:
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <https://github.com/gibson042/ecma262-proposal-JSON-parse-with-source>
> kai zhu
> kaizhu256 at gmail.com <mailto:kaizhu256 at gmail.com>
> 
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <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/20181022/b8fb5b68/attachment-0001.html>


More information about the es-discuss mailing list