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 <michalwa...@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....@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....@gmail.com <mailto:anders.rundgren....@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@mozilla.org <mailto:es-discuss@mozilla.org>
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
