On Sat, Jul 14, 2018 at 9:23 PM Anders Rundgren < 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>> > 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: > Yes; and I did forget to mentions erilaization side but the serlizer could do an additional type check and emit and appropriate thing. 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> > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > _______________________________________________ > > es-discuss mailing list > > 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> 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>> > 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> > > 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
