also, how would you "cast" a BigInt from string to BigInt ?
On Tue, Jul 17, 2018 at 11:49 AM Andrea Giammarchi <
andrea.giammar...@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 <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
