I like the idea, but I don't feel it's *quite* as simple as as just adding an option for serializing BigInts/numbers as explicit integers/floats.
----- Isiah Meadows [email protected] www.isiahmeadows.com On Tue, Aug 14, 2018 at 2:31 PM Michael Theriot <[email protected]> wrote: > > I've been brainstorming a few days and this is the same idea I reached. I > just wasn't sure if returning some kind of special object (JSON.Fragment) was > a good way to handle stringify. > > Elaborating, basically a third argument would come back in JSON.parse reviver > method, which is the actual string that was parsed (not the parsed value). > When stringifying, a JSON.Fragment would not get parsed but inserts the > underlying string value (which must be valid JSON). > > JSON.Fragment would just be a way to use valid, raw strings in JSON. E.g. > JSON.stringify([0]) === JSON.stringify(JSON.Fragment("[0]") > > On Tuesday, August 14, 2018, Michał Wadas <[email protected]> wrote: >> >> Personally, I would like to see: >> - third argument to JSON.parse reviver, "raw string" >> - new class JSON.Fragment accepting any syntactically valid JSON in >> constructor (eg. new JSON.Fragment('99999999999999999') >> - returning JSON.Fragment from JSON.stringify would paste it as-it-is into >> string output >> >> This should cover any Bigint use case without breaking backward >> compatibility. >> >> On Tue, 14 Aug 2018, 07:57 Anders Rundgren, <[email protected]> >> wrote: >>> >>> On 2018-08-14 06:55, J Decker wrote: >>> > my primary usage of json is >>> > https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications#Using_JSON_to_transmit_objects >>> > >>> > in which case JSON.parse( JSON.strinigfy( msg ) ) really needs to result >>> > in the same sort of thing as the input; although I guess dates do get >>> > lost in translation anyway, but they could be handled as numbers with a >>> > few more character exceptions ':','-'(in a number),'Z',' ' the last one >>> > (the space) complicating the whole thing immensely; there is no meaning >>> > of multiple numbers without a ',' between them in JSON, so maybe not so >>> > impossible. >>> > >>> > and given the requirement that seems to be lost, that bigints ONLY >>> > interop with bigints, they MUST decode the same as their encoding; the >>> > JSONnumber type almost works; but requires custom code every time bigints >>> > are used. (much like dates) >>> > >>> > what writing a JSON parser taught me, is the type of a variable is the >>> > type of the data it has; and JSON does a really good job of representing >>> > 99% of generally communicated types. which makes generic code quite >>> > easy... without having to respecify/recast the data, the data is already >>> > the type it is. >>> >>> Since the JSON standard doesn't distinguish between a single bit or >>> BigNumber, I guess you are proposing extensions to JSON? >>> >>> >>> > but there's certainly fewer of me, than of those that thing everything is >>> > perfectly fine, and shouldn't evolve as the langugage has. >>> > but then there's 'don't break the net' and 'this could certainy break the >>> > net'; but since bigints didn't exist before, I guess they shouldn't be >>> > added now, because sending them to old code would break the old code.... >>> > but actually since being added; should also update JSON to support that >>> > number type (although I guess base JSON doesn't suppose ES6 number >>> > encodings like 0x, 0b, etc...) >>> > >>> > and again, since bigints ONLY interop with other bigints, there should be >>> > no chance they will get lost in interpretation. >>> > >>> > can see JSONnumber can aid application handling; but if you send bigints >>> > to an application that doesn't support bigints it's not going to work >>> > anyway; so why not just let existing json.parse throw when it doens't >>> > have bigint support? >>> >>> The proposal is targeting *cross-platform applications* using JSON. The >>> only thing it adds is offering a way to use JSON Number formatting for new >>> numeric types, in addition to the quoting schemes which already are fully >>> supported (and extensively used as well). >>> >>> Example: A java class element like `BigInteger big;` used in a JSON context >>> presumes that all values targeting "big" should be treated as BigIntger >>> (=BigInt). However, there are different practices for formatting >>> BigIntegers in JSON and they are all "right" :-) >>> >>> In essence, the proposal's only ambition is making the ES6 JSON object >>> better aligned with an already established JSON reality. >>> >>> Anders >>> >>> > On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren >>> > <[email protected] <mailto:[email protected]>> >>> > wrote: >>> > >>> > For good or for worse I have written a proposal for >>> > https://github.com/tc39/proposal-bigint/issues/162 >>> > available at >>> > https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6 >>> > >>> > Since the proposal doesn't introduce a default serialization mode, I >>> > guess nobody will be happy :-( >>> > OTOH, a fairly decent rationale for not specifying a default is also >>> > provided :-) >>> > This comment is also worth reading: >>> > https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859 >>> > >>> > >>> > Cheers, >>> > Anders >>> > _______________________________________________ >>> > es-discuss mailing list >>> > [email protected] <mailto:[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
