JSON support for BigInt in ES6.
d3ck0r at gmail.com
Tue Aug 14 04:55:15 UTC 2018
my primary usage of json is
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
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
On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren <
anders.rundgren.net at gmail.com> wrote:
> For good or for worse I have written a proposal for
> available at
> 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:
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss