I think we should move away from guessing and automagically parsing our
JSON. The fact is a JSON number != JS number. Perhaps in userland (or a
proposal...) JSON.parse could return with a JSONNumber object which the
developer decides to convert to BigInt or Number.
On Saturday, July 28, 2018, J Decker <d3c...@gmail.com> wrote:
>
>
> On Sat, Jul 28, 2018 at 6:57 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.
>
>
> The problem with this, 'guessing' whether is't a Number() or a BigInt() is
> that numbers and bigint's don't interop.
>
> {a:123, b:123n}
> " { "a":123, "b":123 }" any expressions that expect B to be a BigInt()
> will fail, becasue it will be in an expression of other bigints.
>
> bigInts aren't just a better Number type, but, rather require other
> bigints for their expressions.
>
>
>
>>
>> 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
