JSON support for BigInt in Chrome/V8
Andrea Giammarchi
andrea.giammarchi at gmail.com
Tue Jul 17 11:27:58 UTC 2018
actually, never mind ... but I find it hilarious
that BigInt('55555555555555555550000000000000000000001') works
but BigInt('55555555555555555550000000000000000000001n') doesn't ^_^;;
Anyway, there is an easy pattern to go around this issue (and all others),
will come back on this.
Best Regards
On Tue, Jul 17, 2018 at 1:25 PM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:
> 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/09249d86/attachment-0001.html>
More information about the es-discuss
mailing list