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
