On 2018-07-28 16:10, Isiah Meadows wrote:
Not serializing BigInt is questionable to me but even that can be solved in
userland.
This is pretty easy for `JSON.stringify`, at least: you specify a
reviver that coerces them to numbers:
```js
JSON.stringify(object, null, (k, v) => typeof v === "bigint" ? Number(v) : v)
```
This code did not run in Chrome 67 and if it had, it would have truncated
values which is probably not what you want.
Although not super elegant, the following code works and would presumably also
work with predecessors using emulated BigInts:
```js
var object = { big: BigInt(555555555555555555555555555n).toString(),
small: 55};
JSON.stringify(object);
```
The deserialization of that is trickier, but it's easy worked around.
By sticking to the conservative/boring approach you can use it today:
```js
var input = JSON.parse('{"big":"555555555555555555555555555","small":55}', (key,
value) =>
key == 'big'
? BigInt(value) // return true BigInt
: value // return everything else unchanged
);
console.log(input);
```
Anders
-----
Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com
On Sat, Jul 28, 2018 at 9:56 AM, Michael Theriot
<michael.lee.ther...@gmail.com> wrote:
In a language with arbitrary integer precision, Python 3 for example, the way to parse a
"BigInt" would just be a plain, human readable number without quotes. The way
to serialize it is the same. Any other kind of representation is out of spec, a
workaround, and belongs in userland.
I think BigInt should serialize the same, not as strings or anything that is
not a number. JSON.parse being unable to parse back into BigInt is a separate
issue. It is solvable by using better parsing methods, not the convenient
built-in one which has other issues. E.g. a streaming JSON parser that lets you
inspect the key name and string being parsed can handle this. Case solved and
you can also redesign your code so you are not creating a temporary object
every single parse that you most likely copy into actual objects later.
Not serializing BigInt is questionable to me but even that can be solved in
userland.
On Saturday, July 14, 2018, Anders Rundgren <anders.rundgren....@gmail.com>
wrote:
var small = BigInt("5");
var big = BigInt("5555555555555555555555555500003");
JSON.stringify([big,small]);
VM330:1 Uncaught TypeError: Do not know how to serialize a BigInt
at JSON.stringify (<anonymous>)
at <anonymous>:1:6
JSON Number serialization has apparently reached a new level (of confusion).
Personally I don't see the problem. XML did just fine without hard-coded data
types.
The JSON type system is basically a relic from JavaScript. As such it has
proved to be quite useful.
However, when you are outside of that scope, the point with the JSON type
system gets pretty much zero since you anyway need to map extended types.
Oracle's JSON-B solution which serializes small values as Number and large values as
String rather than having a unified serialization based on the underlying data type seems
like a pretty broken concept although indeed fully conforming to the JSON specification.
"Like the Devil reads the Bible" as we say in Scandinavia :-)
Adding a couple of double quotes is a major problem? If so, it seems like a
way more useful project making quotes optional for keys (named in a specific
way), like they already are in JavaScript.
Yeah, and of course adding support for comments.
Anders
_______________________________________________
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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
