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
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....@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@mozilla.org <mailto:es-discuss@mozilla.org> <mailto:
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>>
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > >
> > >
> > > _______________________________________________
> > > es-discuss mailing list
> > > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> >
> >
> > On Sat, Jul 14, 2018 at 9:23 PM Anders Rundgren <
> anders.rundgren....@gmail.com <mailto:anders.rundgren....@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....@gmail.com <mailto:anders.rundgren....@gmail.com>
> <mailto:anders.rundgren....@gmail.com <mailto:
> 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
> > >
> > >
> > > 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@mozilla.org <mailto:es-discuss@mozilla.org> <mailto:
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>>
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > >
> > >
> > > _______________________________________________
> > > es-discuss mailing list
> > > es-discuss@mozilla.org <mailto: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
