<div dir="ltr">Why not just use DataURL syntax, something like this:<div><br></div><div>```js</div><div>{</div><div>  "field1": "data:json/bigint,12345678901234567890123456789012345678901234567890123456789012345678901234567890",</div><div>  ...</div><div>}</div><div>```</div><div>This way, even as other objects pop up to be serialized, all that would be needed is another mime type in the format "json/<typename>". I could even see letting the "<typename>" portion hold the non-lowercased, original class name to make it even faster to deserialize such fields without knowing all possible mime types in advance. Still 100% compatible with existing JSON. Still 100% human readable/writable. Very easy to implement, and self consistent.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 28, 2018 at 9:11 AM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Not serializing BigInt is questionable to me but even that can be solved in userland.<br>
<br>
This is pretty easy for `JSON.stringify`, at least: you specify a<br>
reviver that coerces them to numbers:<br>
<br>
```js<br>
JSON.stringify(object, null, (k, v) => typeof v === "bigint" ? Number(v) : v)<br>
```<br>
<br>
The deserialization of that is trickier, but it's easy worked around.<br>
<br>
-----<br>
<br>
Isiah Meadows<br>
<a href="mailto:me@isiahmeadows.com" target="_blank">me@isiahmeadows.com</a><br>
<a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
<br>
On Sat, Jul 28, 2018 at 9:56 AM, Michael Theriot<br>
<<a href="mailto:michael.lee.theriot@gmail.com" target="_blank">michael.lee.theriot@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Not serializing BigInt is questionable to me but even that can be solved in userland.<br>
><br>
> On Saturday, July 14, 2018, Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a>> wrote:<br>
>><br>
>> var small = BigInt("5");<br>
>> var big = BigInt("5555555555555555555555555500003");<br>
>> JSON.stringify([big,small]);<br>
>> VM330:1 Uncaught TypeError: Do not know how to serialize a BigInt<br>
>>     at JSON.stringify (<anonymous>)<br>
>>     at <anonymous>:1:6<br>
>><br>
>> JSON Number serialization has apparently reached a new level (of confusion).<br>
>><br>
>> Personally I don't see the problem.  XML did just fine without hard-coded data types.<br>
>><br>
>> The JSON type system is basically a relic from JavaScript.  As such it has proved to be quite useful.<br>
>> 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.<br>
>><br>
>> 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 :-)<br>
>><br>
>> 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.<br>
>><br>
>> Yeah, and of course adding support for comments.<br>
>><br>
>> Anders<br>
>><br>
>> _______________________________________________<br>
>> es-discuss mailing list<br>
>> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
><br>
><br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>