I'd suggest filing an issue like this directly on the proposal repo. On Sun, Oct 21, 2018 at 12:59 PM Peter Jaszkowiak <[email protected]> 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 <[email protected]> > 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", "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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> 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 >>>>>>> [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> es-discuss mailing list >>>>>>> [email protected] >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>> >>>>>> _______________________________________________ >>>>>> es-discuss mailing list >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
