JSON support for BigInt in ES6.

Tue Aug 14 18:42:43 UTC 2018

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
contact at isiahmeadows.com
www.isiahmeadows.com

On Tue, Aug 14, 2018 at 2:31 PM Michael Theriot
<michael.lee.theriot at gmail.com> 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 <michalwadas at gmail.com> 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, <anders.rundgren.net at gmail.com> 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 <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>> 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
>>> >     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>> >     https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss