The way this conversation is going, we might as well just create a schema-based JSON serialization DSL for both parsing and stringifying. But I don't really see that as helpful in the *language itself* at least as a mandatory part of the spec (maybe an optional built-in module).
I've in the past few months seen similar things come up a few times already. I like the idea of a built-in schema-based JSON validator + parser (it'd be faster than what we currently have), but most things out there suck in some way, mostly just being boilerplatey, and there's a lot of design work to get out of the way first before you can come up with something that doesn't. But as it stands, the only things I'd support for the `JSON` global itself are: 1. Adding separate prototypes for `JSON.stringify(source, options)` and `JSON.parse(source, options)`, so it's easier to extend and comprehend the arguments. 2. Adding an option to parse anything consisting of purely digits (no exponent or decimal) as a BigInt, regardless of size. 3. Adding an option to stringify BigInts into integer-only numbers and normal numbers into unconditional floats. These could be either separate methods or part of a 4th options argument. ----- Isiah Meadows [email protected] www.isiahmeadows.com On Tue, Jul 17, 2018 at 6:52 PM, Michael J. Ryan <[email protected]> wrote: > Out of bounds as you'd still have to parse it, but for encoding, could add > BigInt.prototype.toJSON ... > > On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi <[email protected]> > wrote: >> >> I guess a better example would've been `Boolean('false')` returns true, >> but yeah, I've moved slightly forward already with everything, if you read >> other messages. >> >> Regards. >> >> On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat <[email protected]> >> wrote: >>> >>> On 07/17/2018 04:27 AM, Andrea Giammarchi wrote: >>> > actually, never mind ... but I find it hilarious that >>> > BigInt('55555555555555555550000000000000000000001') works but >>> > BigInt('55555555555555555550000000000000000000001n') doesn't ^_^;; >>> >>> That's no different from how other built-in types work. String('"foo"') >>> doesn't give you the same string as the string literal "foo". >>> >>> Waldemar >> >> _______________________________________________ >> 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
