JSON support for BigInt in Chrome/V8
Andrea Giammarchi
andrea.giammarchi at gmail.com
Tue Jul 17 11:25:24 UTC 2018
P.S. eval / Function is obviously **not** an answer
On Tue, Jul 17, 2018 at 11:53 AM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:
> also, how would you "cast" a BigInt from string to BigInt ?
>
> On Tue, Jul 17, 2018 at 11:49 AM Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> fair enough, so everything that is not `object` or `null` should never
>> use `new`. Is this somehow an indirect rule based on current specs or
>> actually part of the specification?
>>
>>
>>
>> On Tue, Jul 17, 2018 at 11:12 AM J Decker <d3ck0r at gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Jul 17, 2018 at 1:48 AM Andrea Giammarchi <
>>> andrea.giammarchi at gmail.com> wrote:
>>>
>>>> We miss a fundamental feature in JS, the ability to understand if a
>>>> native constructor can be used with `new` or not.
>>>>
>>>> BigInt("5555555555555555555555555500003");
>>>> 5555555555555555555555555500003n
>>>>
>>>> new BigInt("5555555555555555555555555500003");
>>>> VM51:1 Uncaught TypeError: BigInt is not a constructor
>>>>
>>>>
>>> ```
>>> typeof(5n)
>>> "bigint"
>>> ```
>>>
>>> Uint8Array([])
>>>> VM54:1 Uncaught TypeError: Constructor Uint8Array requires 'new'
>>>>
>>>> new Uint8Array([])
>>>> Uint8Array []
>>>>
>>>> Without that knowledge, any attempt to even think about a solution that
>>>> would scale not only with BigInt but with everything else, is kinda futile.
>>>>
>>>> Best Regards.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Jul 15, 2018 at 8:27 AM Anders Rundgren <
>>>> anders.rundgren.net at gmail.com> wrote:
>>>>
>>>>> On 2018-07-15 08:17, J Decker wrote:
>>>>> <snip>
>>>>> > If you want to use BigInt with JSON you have to serialize it
>>>>> yourself:
>>>>> >
>>>>> > Yes; and I did forget to mentions erilaization side but the serlizer
>>>>> could do an additional type check and emit and appropriate thing.
>>>>>
>>>>> It is the "appropriate thing" that is problem; the rest is trivial.
>>>>>
>>>>> Anders
>>>>>
>>>>> > I thought the replacer could be used- but the output of replacer
>>>>> would have to type check to see if it's a bigint too....
>>>>> > https://github.com/v8/v8/blob/master/src/json-stringifier.cc#L305
>>>>> case BIGINT_TYPE: hmm and digging some more there's lots of eexcpetions
>>>>> thrown...
>>>>> >
>>>>> > does Number( "5n" ) ? result in a bigint? No....
>>>>> > ```
>>>>> > Number( "5n" )
>>>>> > NaN
>>>>> > var a = 5n
>>>>> > a
>>>>> > 5n
>>>>> > ```
>>>>> >
>>>>> >
>>>>> > var small = BigInt(5n);
>>>>> > var big = BigInt(5555555555555555555555555500003n);
>>>>> > JSON.stringify([big.toString(),small.toString()]);
>>>>> >
>>>>> > which generates ["5555555555555555555555555500003","5"]
>>>>> >
>>>>> > Anders
>>>>> >
>>>>> > > var small = 5n;
>>>>> > > var big = 5555555555555555555555555500003n;
>>>>> > >
>>>>> > > n suffix as from
>>>>> > > https://github.com/tc39/proposal-bigint
>>>>> > >
>>>>> > > 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.
>>>>> > >
>>>>> > >
>>>>> > > I'd rather not see numbers converted to strings; that would
>>>>> be required to allow application handling of values; at a layer higher than
>>>>> JSON core itself. It is nice that JSON keeps numbers as numbers and
>>>>> strings as strings without needing intimite knowledge about the actual
>>>>> 'types' they end up in.
>>>>> > >
>>>>> > > Comparing numeric length would be a half/useless solution
>>>>> since bigints are required to interop with other bigints only; so small
>>>>> numbers couldn't be 'guessed' and the application would have to provide a
>>>>> reviver.
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > Anders
>>>>> > >
>>>>> > > _______________________________________________
>>>>> > > es-discuss mailing list
>>>>> > > es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>>>> <mailto:es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>>
>>>>> > > https://mail.mozilla.org/listinfo/es-discuss
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > _______________________________________________
>>>>> > > es-discuss mailing list
>>>>> > > es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>>>> > > https://mail.mozilla.org/listinfo/es-discuss
>>>>> > >
>>>>> >
>>>>> >
>>>>> > On Sat, Jul 14, 2018 at 9:23 PM Anders Rundgren <
>>>>> anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>>
>>>>> wrote:
>>>>> >
>>>>> > On 2018-07-15 04:27, J Decker wrote:
>>>>> > >
>>>>> > >
>>>>> > > On Sat, Jul 14, 2018 at 1:36 AM Anders Rundgren <
>>>>> anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>
>>>>> <mailto:anders.rundgren.net at gmail.com <mailto:
>>>>> anders.rundgren.net at 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
>>>>> > >
>>>>> > >
>>>>> > > is BigInt the only way to create a BigInt ? Or did they also
>>>>> implement the 'n' suffix, which I noted here
>>>>> https://github.com/tc39/proposal-bigint/issues/24#issuecomment-392307848
>>>>> would easily distinguish bigint from other numbers; and be easy to add on
>>>>> the parsing side; and call BigInt(xxx) instead of Number(xxx).
>>>>> >
>>>>> > This problem is related to the BigInt object itself. If you
>>>>> create such using the 'n' notation you get the same result.
>>>>> >
>>>>> > If you want to use BigInt with JSON you have to serialize it
>>>>> yourself:
>>>>> >
>>>>> > var small = BigInt(5n);
>>>>> > var big = BigInt(5555555555555555555555555500003n);
>>>>> > JSON.stringify([big.toString(),small.toString()]);
>>>>> >
>>>>> > which generates ["5555555555555555555555555500003","5"]
>>>>> >
>>>>> > Anders
>>>>> >
>>>>> > > var small = 5n;
>>>>> > > var big = 5555555555555555555555555500003n;
>>>>> > >
>>>>> > > n suffix as from
>>>>> > > https://github.com/tc39/proposal-bigint
>>>>> > >
>>>>> > > 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.
>>>>> > >
>>>>> > >
>>>>> > > I'd rather not see numbers converted to strings; that would
>>>>> be required to allow application handling of values; at a layer higher than
>>>>> JSON core itself. It is nice that JSON keeps numbers as numbers and
>>>>> strings as strings without needing intimite knowledge about the actual
>>>>> 'types' they end up in.
>>>>> > >
>>>>> > > Comparing numeric length would be a half/useless solution
>>>>> since bigints are required to interop with other bigints only; so small
>>>>> numbers couldn't be 'guessed' and the application would have to provide a
>>>>> reviver.
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > Anders
>>>>> > >
>>>>> > > _______________________________________________
>>>>> > > es-discuss mailing list
>>>>> > > es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>>>> <mailto:es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>>
>>>>> > > https://mail.mozilla.org/listinfo/es-discuss
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > _______________________________________________
>>>>> > > es-discuss mailing list
>>>>> > > es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>>>> > > https://mail.mozilla.org/listinfo/es-discuss
>>>>> > >
>>>>> >
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180717/05f2b450/attachment-0001.html>
More information about the es-discuss
mailing list