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 <d3c...@gmail.com> wrote: > > > On Tue, Jul 17, 2018 at 1:48 AM Andrea Giammarchi < > andrea.giammar...@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....@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 >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss