JSON support for BigInt in Chrome/V8

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Michael J. Ryan
Out of bounds as you'd still have to parse it, but for encoding, could add BigInt.prototype.toJSON ...

On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi <[hidden email]> wrote:
I guess a better example would've been `Boolean('false')` returns true, but yeah, I've moved slightly forward already with everything, if you read other messages.

Regards.

On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat <[hidden email]> wrote:
On 07/17/2018 04:27 AM, Andrea Giammarchi wrote:
> actually, never mind ... but I find it hilarious that BigInt('55555555555555555550000000000000000000001') works but BigInt('55555555555555555550000000000000000000001n') doesn't ^_^;;

That's no different from how other built-in types work.  String('"foo"') doesn't give you the same string as the string literal "foo".

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Jordan Harband
In reply to this post by Jordan Harband
You can permanently fix any such type-checks by `function isObject(x) { return x && (typeof x === 'object' || typeof x === 'function'); }`, or `function isObject(x) { return x && Object(x) === x; }`, etc.

On Tue, Jul 17, 2018 at 7:05 PM, Kai Zhu <[hidden email]> wrote:
>You already can't use `new` with `Symbol`, and you don't ever want to use `new` with a primitive's constructor anyways.

this would be *okay* if we limit the number of primitive-types in the language to a small-number (maybe add BigDecimal, but that's it), so its easy to remember.  i'm concerned that we have one too many needless primitives already (Symbol should've been an object, and it not requiring 'new' looks more like a wart to me).

adding more primitives at this point, will only make this pedantic-rule look more like a wart, and trip-up beginners (and their prejudice on the language's inconsistencies).  it also complicates integration-work on web-projects, due to difficulty baton-passing new primitives around via JSON, and having to continually refactor type-checks that rely on typeof.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Isiah Meadows-2
In reply to this post by Michael J. Ryan
The way this conversation is going, we might as well just create a
schema-based JSON serialization DSL for both parsing and stringifying.
But I don't really see that as helpful in the *language itself* at
least as a mandatory part of the spec (maybe an optional built-in
module).

I've in the past few months seen similar things come up a few times
already. I like the idea of a built-in schema-based JSON validator +
parser (it'd be faster than what we currently have), but most things
out there suck in some way, mostly just being boilerplatey, and
there's a lot of design work to get out of the way first before you
can come up with something that doesn't.

But as it stands, the only things I'd support for the `JSON` global itself are:

1. Adding separate prototypes for `JSON.stringify(source, options)`
and `JSON.parse(source, options)`, so it's easier to extend and
comprehend the arguments.
2. Adding an option to parse anything consisting of purely digits (no
exponent or decimal) as a BigInt, regardless of size.
3. Adding an option to stringify BigInts into integer-only numbers and
normal numbers into unconditional floats.

These could be either separate methods or part of a 4th options argument.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Tue, Jul 17, 2018 at 6:52 PM, Michael J. Ryan <[hidden email]> wrote:

> Out of bounds as you'd still have to parse it, but for encoding, could add
> BigInt.prototype.toJSON ...
>
> On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi <[hidden email]>
> wrote:
>>
>> I guess a better example would've been `Boolean('false')` returns true,
>> but yeah, I've moved slightly forward already with everything, if you read
>> other messages.
>>
>> Regards.
>>
>> On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat <[hidden email]>
>> wrote:
>>>
>>> On 07/17/2018 04:27 AM, Andrea Giammarchi wrote:
>>> > actually, never mind ... but I find it hilarious that
>>> > BigInt('55555555555555555550000000000000000000001') works but
>>> > BigInt('55555555555555555550000000000000000000001n') doesn't ^_^;;
>>>
>>> That's no different from how other built-in types work.  String('"foo"')
>>> doesn't give you the same string as the string literal "foo".
>>>
>>>      Waldemar
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Anders Rundgren-2
Serializing BigInts as quoted strings is compatible with Java JSON-B, Json.NET and can be poly-filled for older JS implementations.

In addition, this is also compatible with non-schema based parsing.

AFAIK, no IETF standard to date which depends on extended numbers (like JOSE) break the I-JSON recommendations.

Anders

On 2018-07-18 06:16, Isiah Meadows wrote:

> The way this conversation is going, we might as well just create a
> schema-based JSON serialization DSL for both parsing and stringifying.
> But I don't really see that as helpful in the *language itself* at
> least as a mandatory part of the spec (maybe an optional built-in
> module).
>
> I've in the past few months seen similar things come up a few times
> already. I like the idea of a built-in schema-based JSON validator +
> parser (it'd be faster than what we currently have), but most things
> out there suck in some way, mostly just being boilerplatey, and
> there's a lot of design work to get out of the way first before you
> can come up with something that doesn't.
>
> But as it stands, the only things I'd support for the `JSON` global itself are:
>
> 1. Adding separate prototypes for `JSON.stringify(source, options)`
> and `JSON.parse(source, options)`, so it's easier to extend and
> comprehend the arguments.
> 2. Adding an option to parse anything consisting of purely digits (no
> exponent or decimal) as a BigInt, regardless of size.
> 3. Adding an option to stringify BigInts into integer-only numbers and
> normal numbers into unconditional floats.
>
> These could be either separate methods or part of a 4th options argument.
>
> -----
>
> Isiah Meadows
> [hidden email]
> www.isiahmeadows.com
>
>
> On Tue, Jul 17, 2018 at 6:52 PM, Michael J. Ryan <[hidden email]> wrote:
>> Out of bounds as you'd still have to parse it, but for encoding, could add
>> BigInt.prototype.toJSON ...
>>
>> On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi <[hidden email]>
>> wrote:
>>>
>>> I guess a better example would've been `Boolean('false')` returns true,
>>> but yeah, I've moved slightly forward already with everything, if you read
>>> other messages.
>>>
>>> Regards.
>>>
>>> On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat <[hidden email]>
>>> wrote:
>>>>
>>>> On 07/17/2018 04:27 AM, Andrea Giammarchi wrote:
>>>>> actually, never mind ... but I find it hilarious that
>>>>> BigInt('55555555555555555550000000000000000000001') works but
>>>>> BigInt('55555555555555555550000000000000000000001n') doesn't ^_^;;
>>>>
>>>> That's no different from how other built-in types work.  String('"foo"')
>>>> doesn't give you the same string as the string literal "foo".
>>>>
>>>>       Waldemar
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

J Decker
In reply to this post by Isiah Meadows-2


On Tue, Jul 17, 2018 at 9:16 PM Isiah Meadows <[hidden email]> wrote:
The way this conversation is going, we might as well just create a
schema-based JSON serialization DSL for both parsing and stringifying.
But I don't really see that as helpful in the *language itself* at
least as a mandatory part of the spec (maybe an optional built-in
module).

I've in the past few months seen similar things come up a few times
already. I like the idea of a built-in schema-based JSON validator +
parser (it'd be faster than what we currently have), but most things
out there suck in some way, mostly just being boilerplatey, and
there's a lot of design work to get out of the way first before you
can come up with something that doesn't.

But as it stands, the only things I'd support for the `JSON` global itself are:

1. Adding separate prototypes for `JSON.stringify(source, options)`
and `JSON.parse(source, options)`, so it's easier to extend and
comprehend the arguments.
2. Adding an option to parse anything consisting of purely digits (no
exponent or decimal) as a BigInt, regardless of size.
This won't work....

``` desired object
{ a : 123, b : 123n }
```

``` json
{ "a":123 ,
  "b":123 }
```

 function test( json ) { 
   var c = json.a * 5;
   var BIc = json.b * 5n;
}

if long numbers only translate to bigint (and small as Number); the calc for 'BIc' fails.
if everything is translated to bigint  the calc for 'c' fails.

3. Adding an option to stringify BigInts into integer-only numbers and
normal numbers into unconditional floats.


 
These could be either separate methods or part of a 4th options argument.


Well; Since JSON (JavaScript Object Notation) there's now available to JS a feature that an 'n' suffix can be applied to a number.  Seems JSON should just inherit that.

Although I would like to see a better method than eval() to translate the input string from JSON for say { d : 123n }; right now within JS I'd have to use EVAL; in V8 I could just create a BigInt::new()....

(and RE: eval, not saying it's a GOOD solution; it's just apparently the only solution ATM; other than splicing the string.)
 
-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Tue, Jul 17, 2018 at 6:52 PM, Michael J. Ryan <[hidden email]> wrote:
> Out of bounds as you'd still have to parse it, but for encoding, could add
> BigInt.prototype.toJSON ...
>
> On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi <[hidden email]>
> wrote:
>>
>> I guess a better example would've been `Boolean('false')` returns true,
>> but yeah, I've moved slightly forward already with everything, if you read
>> other messages.
>>
>> Regards.
>>
>> On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat <[hidden email]>
>> wrote:
>>>
>>> On 07/17/2018 04:27 AM, Andrea Giammarchi wrote:
>>> > actually, never mind ... but I find it hilarious that
>>> > BigInt('55555555555555555550000000000000000000001') works but
>>> > BigInt('55555555555555555550000000000000000000001n') doesn't ^_^;;
>>>
>>> That's no different from how other built-in types work.  String('"foo"')
>>> doesn't give you the same string as the string literal "foo".
>>>
>>>      Waldemar
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Andrew Paprocki
On Wed, Jul 18, 2018 at 5:03 AM, J Decker <[hidden email]> wrote:

Well; Since JSON (JavaScript Object Notation) there's now available to JS a feature that an 'n' suffix can be applied to a number.  Seems JSON should just inherit that.

json.org states:

"It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999."

ECMA-404 states:

"JSON stands for JavaScript Object Notation and was inspired by the object literals of JavaScript aka ECMAScript as defined in the ECMAScript Language Specification, Third Edition [1]. However, it does not attempt to impose ECMAScript’s internal data representations on other programming languages. Instead, it shares a small subset of ECMAScript’s syntax with all other programming languages."

The 3rd edition did not contain the 'n' suffix, and neither indicate that new ES features should be added to JSON.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Isiah Meadows-2
In reply to this post by J Decker
This won't work....

>
> ``` desired object
> { a : 123, b : 123n }
> ```
>
> ``` json
> { "a":123 ,
>   "b":123 }
> ```
>
>  function test( json ) {
>    var c = json.a * 5;
>    var BIc = json.b * 5n;
> }
>
> if long numbers only translate to bigint (and small as Number); the calc for
> 'BIc' fails.
> if everything is translated to bigint  the calc for 'c' fails.

I think you missed my point: I'm suggesting an extra option to where
floats are parsed differently from integers.

```js
// JSON
{"a": 123.0, "b": 123}

// Parsed normally
{a: 123, b: 123}

// Parsed with option
{a: 123, b: 123n}
```

So given this, the test would be exactly what's expected with the option.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Wed, Jul 18, 2018 at 5:03 AM, J Decker <[hidden email]> wrote:

>
>
> On Tue, Jul 17, 2018 at 9:16 PM Isiah Meadows <[hidden email]>
> wrote:
>>
>> The way this conversation is going, we might as well just create a
>> schema-based JSON serialization DSL for both parsing and stringifying.
>> But I don't really see that as helpful in the *language itself* at
>> least as a mandatory part of the spec (maybe an optional built-in
>> module).
>>
>> I've in the past few months seen similar things come up a few times
>> already. I like the idea of a built-in schema-based JSON validator +
>> parser (it'd be faster than what we currently have), but most things
>> out there suck in some way, mostly just being boilerplatey, and
>> there's a lot of design work to get out of the way first before you
>> can come up with something that doesn't.
>>
>> But as it stands, the only things I'd support for the `JSON` global itself
>> are:
>>
>> 1. Adding separate prototypes for `JSON.stringify(source, options)`
>> and `JSON.parse(source, options)`, so it's easier to extend and
>> comprehend the arguments.
>> 2. Adding an option to parse anything consisting of purely digits (no
>> exponent or decimal) as a BigInt, regardless of size.
>
> This won't work....
>
> ``` desired object
> { a : 123, b : 123n }
> ```
>
> ``` json
> { "a":123 ,
>   "b":123 }
> ```
>
>  function test( json ) {
>    var c = json.a * 5;
>    var BIc = json.b * 5n;
> }
>
> if long numbers only translate to bigint (and small as Number); the calc for
> 'BIc' fails.
> if everything is translated to bigint  the calc for 'c' fails.
>
>> 3. Adding an option to stringify BigInts into integer-only numbers and
>> normal numbers into unconditional floats.
>>
>
>
>>
>> These could be either separate methods or part of a 4th options argument.
>>
>
> Well; Since JSON (JavaScript Object Notation) there's now available to JS a
> feature that an 'n' suffix can be applied to a number.  Seems JSON should
> just inherit that.
>
> Although I would like to see a better method than eval() to translate the
> input string from JSON for say { d : 123n }; right now within JS I'd have to
> use EVAL; in V8 I could just create a BigInt::new()....
>
> (and RE: eval, not saying it's a GOOD solution; it's just apparently the
> only solution ATM; other than splicing the string.)
>
>>
>> -----
>>
>> Isiah Meadows
>> [hidden email]
>> www.isiahmeadows.com
>>
>>
>> On Tue, Jul 17, 2018 at 6:52 PM, Michael J. Ryan <[hidden email]>
>> wrote:
>> > Out of bounds as you'd still have to parse it, but for encoding, could
>> > add
>> > BigInt.prototype.toJSON ...
>> >
>> > On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> I guess a better example would've been `Boolean('false')` returns true,
>> >> but yeah, I've moved slightly forward already with everything, if you
>> >> read
>> >> other messages.
>> >>
>> >> Regards.
>> >>
>> >> On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat <[hidden email]>
>> >> wrote:
>> >>>
>> >>> On 07/17/2018 04:27 AM, Andrea Giammarchi wrote:
>> >>> > actually, never mind ... but I find it hilarious that
>> >>> > BigInt('55555555555555555550000000000000000000001') works but
>> >>> > BigInt('55555555555555555550000000000000000000001n') doesn't ^_^;;
>> >>>
>> >>> That's no different from how other built-in types work.
>> >>> String('"foo"')
>> >>> doesn't give you the same string as the string literal "foo".
>> >>>
>> >>>      Waldemar
>> >>
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> [hidden email]
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > [hidden email]
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

kai zhu
reposting due to previous mail-rejection (vpn issue with gmail in china)

>You already can't use `new` with `Symbol`, and you don't ever want to use `new` with a primitive's constructor anyways.

this rule would be *okay* if we limit the number of primitive-types in
the language to a small-number (maybe add BigDecimal, but that's it),
so its easy to remember.  i'm already concerned that we have one too
many needless primitives (Symbol should've been an object similar to
Promise, and even more so since its use-case is marginal).

adding more primitives at this point, will only make this
pedantic-rule look more like a wart, and trip-up beginners (and their
prejudice on the language's inconsistencies).  it also complicates
integration-work on web-projects, due to difficulty baton-passing new
primitives around via JSON, and having to continually refactor
type-checks that rely on typeof.



On 7/17/18, Andrea Giammarchi <[hidden email]> 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 <[hidden email]> wrote:
>
>>
>>
>> On Tue, Jul 17, 2018 at 1:48 AM Andrea Giammarchi <
>> [hidden email]> 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.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Jordan Harband
I'm not sure why anything needs remembering - with no other knowledge except "how the thing you're trying to create is used", I'd hope that it's apparent whether it's an object or a primitive.

On Thu, Jul 19, 2018 at 2:43 PM, kai zhu <[hidden email]> wrote:
reposting due to previous mail-rejection (vpn issue with gmail in china)

>You already can't use `new` with `Symbol`, and you don't ever want to use `new` with a primitive's constructor anyways.

this rule would be *okay* if we limit the number of primitive-types in
the language to a small-number (maybe add BigDecimal, but that's it),
so its easy to remember.  i'm already concerned that we have one too
many needless primitives (Symbol should've been an object similar to
Promise, and even more so since its use-case is marginal).

adding more primitives at this point, will only make this
pedantic-rule look more like a wart, and trip-up beginners (and their
prejudice on the language's inconsistencies).  it also complicates
integration-work on web-projects, due to difficulty baton-passing new
primitives around via JSON, and having to continually refactor
type-checks that rely on typeof.



On 7/17/18, Andrea Giammarchi <[hidden email]> 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 <[hidden email]> wrote:
>
>>
>>
>> On Tue, Jul 17, 2018 at 1:48 AM Andrea Giammarchi <
>> [hidden email]> 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.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

T.J. Crowder-2
Not having JSON support for BigInt is a big problem. But the fact exists that JSON does not cover everything. It doesn't cover Dates, Maps, Sets, Symbols...

Until/unless the successor to JSON (whatever it may be) is created and adopted, a process that will take years, let's take a pragmatic approach similar to the pragmatic approach taken in relation to Dates: Abuse a string.

```js
BigInt.prototype.toJSON = function() {
    return `/BigInt(${this.toString()})/`;
};
```

Then this:

```js
console.log(JSON.stringify({n:10n}));
```

outputs

```
{"n":"/BigInt(10)/"}
```

Do I like it? Not even a little bit. But as a pragmatic way forward, providing `toJSON` on BigInt's prototype and having it produce something along these lines seems like Better Than Nothing™. Date's `toJSON` produces a string in a readily-recognized format, after all. I'd also suggest `BigInt.fromJSON` which validated and parsed the string in that format.

This would put us where Dates are now, but without competing standards for them (ISO string vs.` /Date(epochval)/`).

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Anders Rundgren-2
Thanx T.J.

With your suggestion there are now not less than FIVE proposals on the table for dealing with BigInt JSON serialization:

*RFC8259: 123456789123456789123456789
ES6 enhanced: 123456789123456789123456789n
Typed: "/BigInt(123456789123456789123456789)/"
*Adaptive: "123456789123456789123456789" respectively 123456789
*Conservative: "123456789123456789123456789"

Maybe Carsten Bormann after all is right, it is time to jump the JSON ship!

Before the industry takes the leap to CBOR, I personally stick to the conservative path because it appears to be compatible ("usable" is maybe a better word) with just about everything out there.

I wouldn't completely ignore the fact that XML did just fine without any explicit type information at all.  OpenAPI addresses this for Date to take an example.  They are though still grappling with BigInt :-)

Cheers,
Anders

* Denotes implemented/in use

On 2018-07-26 18:51, T.J. Crowder wrote:

> Not having JSON support for BigInt is a big problem. But the fact exists that JSON does not cover everything. It doesn't cover Dates, Maps, Sets, Symbols...
>
> Until/unless the successor to JSON (whatever it may be) is created and adopted, a process that will take years, let's take a pragmatic approach similar to the pragmatic approach taken in relation to Dates: Abuse a string.
>
> ```js
> BigInt.prototype.toJSON = function() {
>      return `/BigInt(${this.toString()})/`;
> };
> ```
>
> Then this:
>
> ```js
> console.log(JSON.stringify({n:10n}));
> ```
>
> outputs
>
> ```
> {"n":"/BigInt(10)/"}
> ```
>
> Do I like it? Not even a little bit. But as a pragmatic way forward, providing `toJSON` on BigInt's prototype and having it produce something along these lines seems like Better Than Nothing™. Date's `toJSON` produces a string in a readily-recognized format, after all. I'd also suggest `BigInt.fromJSON` which validated and parsed the string in that format.
>
> This would put us where Dates are now, but without competing standards for them (ISO string vs.` /Date(epochval)/`).
>
> -- T.J. Crowder
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Michael Theriot
In reply to this post by Anders Rundgren-2
In a language with arbitrary integer precision, Python 3 for example, the way to parse a "BigInt" would just be a plain, human readable number without quotes. The way to serialize it is the same. Any other kind of representation is out of spec, a workaround, and belongs in userland.

I think BigInt should serialize the same, not as strings or anything that is not a number. JSON.parse being unable to parse back into BigInt is a separate issue. It is solvable by using better parsing methods, not the convenient built-in one which has other issues. E.g. a streaming JSON parser that lets you inspect the key name and string being parsed can handle this. Case solved and you can also redesign your code so you are not creating a temporary object every single parse that you most likely copy into actual objects later.

Not serializing BigInt is questionable to me but even that can be solved in userland.

On Saturday, July 14, 2018, Anders Rundgren <[hidden email]> 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

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.

Anders

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Isiah Meadows-2
> Not serializing BigInt is questionable to me but even that can be solved in userland.

This is pretty easy for `JSON.stringify`, at least: you specify a
reviver that coerces them to numbers:

```js
JSON.stringify(object, null, (k, v) => typeof v === "bigint" ? Number(v) : v)
```

The deserialization of that is trickier, but it's easy worked around.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Sat, Jul 28, 2018 at 9:56 AM, Michael Theriot
<[hidden email]> wrote:

>
> In a language with arbitrary integer precision, Python 3 for example, the way to parse a "BigInt" would just be a plain, human readable number without quotes. The way to serialize it is the same. Any other kind of representation is out of spec, a workaround, and belongs in userland.
>
> I think BigInt should serialize the same, not as strings or anything that is not a number. JSON.parse being unable to parse back into BigInt is a separate issue. It is solvable by using better parsing methods, not the convenient built-in one which has other issues. E.g. a streaming JSON parser that lets you inspect the key name and string being parsed can handle this. Case solved and you can also redesign your code so you are not creating a temporary object every single parse that you most likely copy into actual objects later.
>
> Not serializing BigInt is questionable to me but even that can be solved in userland.
>
> On Saturday, July 14, 2018, Anders Rundgren <[hidden email]> 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
>>
>> 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.
>>
>> Anders
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Anders Rundgren-2
On 2018-07-28 16:10, Isiah Meadows wrote:
>> Not serializing BigInt is questionable to me but even that can be solved in userland.
>
> This is pretty easy for `JSON.stringify`, at least: you specify a
> reviver that coerces them to numbers:
>
> ```js
> JSON.stringify(object, null, (k, v) => typeof v === "bigint" ? Number(v) : v)
> ```

This code did not run in Chrome 67 and if it had, it would have truncated values which is probably not what you want.


Although not super elegant, the following code works and would presumably also work with predecessors using emulated BigInts:

```js
var object = { big: BigInt(555555555555555555555555555n).toString(),
                small: 55};
JSON.stringify(object);
```

>
> The deserialization of that is trickier, but it's easy worked around.
>

By sticking to the conservative/boring approach you can use it today:

```js
var input = JSON.parse('{"big":"555555555555555555555555555","small":55}', (key, value) =>
   key == 'big'
     ? BigInt(value) // return true BigInt
     : value     // return everything else unchanged
);
console.log(input);
```

Anders




> -----
>
> Isiah Meadows
> [hidden email]
> www.isiahmeadows.com
>
> On Sat, Jul 28, 2018 at 9:56 AM, Michael Theriot
> <[hidden email]> wrote:
>>
>> In a language with arbitrary integer precision, Python 3 for example, the way to parse a "BigInt" would just be a plain, human readable number without quotes. The way to serialize it is the same. Any other kind of representation is out of spec, a workaround, and belongs in userland.
>>
>> I think BigInt should serialize the same, not as strings or anything that is not a number. JSON.parse being unable to parse back into BigInt is a separate issue. It is solvable by using better parsing methods, not the convenient built-in one which has other issues. E.g. a streaming JSON parser that lets you inspect the key name and string being parsed can handle this. Case solved and you can also redesign your code so you are not creating a temporary object every single parse that you most likely copy into actual objects later.
>>
>> Not serializing BigInt is questionable to me but even that can be solved in userland.
>>
>> On Saturday, July 14, 2018, Anders Rundgren <[hidden email]> 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
>>>
>>> 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.
>>>
>>> Anders
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Ranando King
In reply to this post by Isiah Meadows-2
Why not just use DataURL syntax, something like this:

```js
{
  "field1": "data:json/bigint,12345678901234567890123456789012345678901234567890123456789012345678901234567890",
  ...
}
```
This way, even as other objects pop up to be serialized, all that would be needed is another mime type in the format "json/<typename>". I could even see letting the "<typename>" portion hold the non-lowercased, original class name to make it even faster to deserialize such fields without knowing all possible mime types in advance. Still 100% compatible with existing JSON. Still 100% human readable/writable. Very easy to implement, and self consistent.

On Sat, Jul 28, 2018 at 9:11 AM Isiah Meadows <[hidden email]> wrote:
> Not serializing BigInt is questionable to me but even that can be solved in userland.

This is pretty easy for `JSON.stringify`, at least: you specify a
reviver that coerces them to numbers:

```js
JSON.stringify(object, null, (k, v) => typeof v === "bigint" ? Number(v) : v)
```

The deserialization of that is trickier, but it's easy worked around.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Sat, Jul 28, 2018 at 9:56 AM, Michael Theriot
<[hidden email]> wrote:
>
> In a language with arbitrary integer precision, Python 3 for example, the way to parse a "BigInt" would just be a plain, human readable number without quotes. The way to serialize it is the same. Any other kind of representation is out of spec, a workaround, and belongs in userland.
>
> I think BigInt should serialize the same, not as strings or anything that is not a number. JSON.parse being unable to parse back into BigInt is a separate issue. It is solvable by using better parsing methods, not the convenient built-in one which has other issues. E.g. a streaming JSON parser that lets you inspect the key name and string being parsed can handle this. Case solved and you can also redesign your code so you are not creating a temporary object every single parse that you most likely copy into actual objects later.
>
> Not serializing BigInt is questionable to me but even that can be solved in userland.
>
> On Saturday, July 14, 2018, Anders Rundgren <[hidden email]> 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
>>
>> 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.
>>
>> Anders
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Anders Rundgren-2
On 2018-07-28 16:52, Ranando King wrote:

> Why not just use DataURL syntax, something like this:
>
> ```js
> {
>    "field1": "data:json/bigint,12345678901234567890123456789012345678901234567890123456789012345678901234567890",
>    ...
> }
> ```
> This way, even as other objects pop up to be serialized, all that would be needed is another mime type in the format "json/<typename>". I could even see letting the "<typename>" portion hold the non-lowercased, original class name to make it even faster to deserialize such fields without knowing all possible mime types in advance. Still 100% compatible with existing JSON. Still 100% human readable/writable. Very easy to implement, and self consistent.
>

I think the issue is rather: What problem do we want to solve?

It is pretty obvious that there is no "perfect" solution.

XML proves that there is no need for explicit type information in an information exchange format. Most sophisticated systems map keys in some way making explicit type information redundant.  That JSON do have a set of distinct data types is great, but extending that type scheme outside of the original JavaScript core, IMO only creates problems.  Nobody (in their right mind) would even think of designing a typed format where everything from a byte to BigDecimal would be represented as a single type.

Anders
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Ranando King
Don't get me wrong. I didn't suggest a means of extending JSON. I suggested a means of consistently and easily reversibly serializing anything that is not natively handled by JSON already. I think JSON is a fairly complete syntax for most purposes. I wish it had a reference type so that recursive structures could be encoded as well, but the suggestion I've just made can even be used to encode that.

On Sat, Jul 28, 2018 at 10:52 AM Anders Rundgren <[hidden email]> wrote:
On 2018-07-28 16:52, Ranando King wrote:
> Why not just use DataURL syntax, something like this:
>
> ```js
> {
>    "field1": "data:json/bigint,12345678901234567890123456789012345678901234567890123456789012345678901234567890",
>    ...
> }
> ```
> This way, even as other objects pop up to be serialized, all that would be needed is another mime type in the format "json/<typename>". I could even see letting the "<typename>" portion hold the non-lowercased, original class name to make it even faster to deserialize such fields without knowing all possible mime types in advance. Still 100% compatible with existing JSON. Still 100% human readable/writable. Very easy to implement, and self consistent.
>

I think the issue is rather: What problem do we want to solve?

It is pretty obvious that there is no "perfect" solution.

XML proves that there is no need for explicit type information in an information exchange format. Most sophisticated systems map keys in some way making explicit type information redundant.  That JSON do have a set of distinct data types is great, but extending that type scheme outside of the original JavaScript core, IMO only creates problems.  Nobody (in their right mind) would even think of designing a typed format where everything from a byte to BigDecimal would be represented as a single type.

Anders

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

J Decker
In reply to this post by Michael Theriot


On Sat, Jul 28, 2018 at 6:57 AM Michael Theriot <[hidden email]> wrote:
In a language with arbitrary integer precision, Python 3 for example, the way to parse a "BigInt" would just be a plain, human readable number without quotes. The way to serialize it is the same. Any other kind of representation is out of spec, a workaround, and belongs in userland.

The problem with this, 'guessing' whether is't a Number() or a BigInt() is that numbers and bigint's don't interop.

{a:123, b:123n}
" { "a":123, "b":123 }"  any expressions that expect B to be a BigInt() will fail, becasue it will be in an expression of other bigints.

bigInts aren't just a better Number type, but, rather require other bigints for their expressions.

 

I think BigInt should serialize the same, not as strings or anything that is not a number. JSON.parse being unable to parse back into BigInt is a separate issue. It is solvable by using better parsing methods, not the convenient built-in one which has other issues. E.g. a streaming JSON parser that lets you inspect the key name and string being parsed can handle this. Case solved and you can also redesign your code so you are not creating a temporary object every single parse that you most likely copy into actual objects later.

Not serializing BigInt is questionable to me but even that can be solved in userland.

On Saturday, July 14, 2018, Anders Rundgren <[hidden email]> 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

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.

Anders

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Anders Rundgren-2
In reply to this post by Ranando King
On 2018-07-28 18:07, Ranando King wrote:
> Don't get me wrong. I didn't suggest a means of extending JSON. I suggested a
> means of consistently and easily reversibly serializing anything that is not
> natively handled by JSON already.

Sure, I got that.  It would obviously work as well.
The problem is that JavaScript's BigInt is rather late in the game. The non-JavaScript platforms already have defined BigInt support, but in an *inconsistent* way.


> I think JSON is a fairly complete syntax for most purposes.

Yes, if you stick to the JavaScript core types defined some 15-20 years back.  Outside of that things are slightly less complete, at least if you include implementations as well.


> I wish it had a reference type so that recursive structures could be encoded as well, but the suggestion I've just made can even be used to encode that.

Doesn't JSON schema (disclaimer: I'm not a user), provide such things?

Anders


> On Sat, Jul 28, 2018 at 10:52 AM Anders Rundgren <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 2018-07-28 16:52, Ranando King wrote:
>      > Why not just use DataURL syntax, something like this:
>      >
>      > ```js
>      > {
>      >    "field1": "data:json/bigint,12345678901234567890123456789012345678901234567890123456789012345678901234567890",
>      >    ...
>      > }
>      > ```
>      > This way, even as other objects pop up to be serialized, all that would be needed is another mime type in the format "json/<typename>". I could even see letting the "<typename>" portion hold the non-lowercased, original class name to make it even faster to deserialize such fields without knowing all possible mime types in advance. Still 100% compatible with existing JSON. Still 100% human readable/writable. Very easy to implement, and self consistent.
>      >
>
>     I think the issue is rather: What problem do we want to solve?
>
>     It is pretty obvious that there is no "perfect" solution.
>
>     XML proves that there is no need for explicit type information in an information exchange format. Most sophisticated systems map keys in some way making explicit type information redundant.  That JSON do have a set of distinct data types is great, but extending that type scheme outside of the original JavaScript core, IMO only creates problems.  Nobody (in their right mind) would even think of designing a typed format where everything from a byte to BigDecimal would be represented as a single type.
>
>     Anders
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in Chrome/V8

Michael Theriot
In reply to this post by J Decker
I think we should move away from guessing and automagically parsing our JSON. The fact is a JSON number != JS number. Perhaps in userland (or a proposal...) JSON.parse could return with a JSONNumber object which the developer decides to convert to BigInt or Number.

On Saturday, July 28, 2018, J Decker <[hidden email]> wrote:


On Sat, Jul 28, 2018 at 6:57 AM Michael Theriot <[hidden email]> wrote:
In a language with arbitrary integer precision, Python 3 for example, the way to parse a "BigInt" would just be a plain, human readable number without quotes. The way to serialize it is the same. Any other kind of representation is out of spec, a workaround, and belongs in userland.

The problem with this, 'guessing' whether is't a Number() or a BigInt() is that numbers and bigint's don't interop.

{a:123, b:123n}
" { "a":123, "b":123 }"  any expressions that expect B to be a BigInt() will fail, becasue it will be in an expression of other bigints.

bigInts aren't just a better Number type, but, rather require other bigints for their expressions.

 

I think BigInt should serialize the same, not as strings or anything that is not a number. JSON.parse being unable to parse back into BigInt is a separate issue. It is solvable by using better parsing methods, not the convenient built-in one which has other issues. E.g. a streaming JSON parser that lets you inspect the key name and string being parsed can handle this. Case solved and you can also redesign your code so you are not creating a temporary object every single parse that you most likely copy into actual objects later.

Not serializing BigInt is questionable to me but even that can be solved in userland.

On Saturday, July 14, 2018, Anders Rundgren <[hidden email]> 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

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.

Anders

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
123