Rob Ede (2018-07-29T11:04:16.000Z)
robjtede at icloud.com (2018-07-30T11:49:32.243Z)
+1 on getting this sorted before stage 4 As people have said before, JSON already supports BigInts. We of course need to preserve backwards compatibility with JS and try not to break how other languages use JSON. I think the best way to satisfy everyone is to give ourselves some flexibility going forwards and JSONifying BigInts as strings doesn’t allow JSON to do what it *can* do. That and it breaks the idea that JSON.parse(JSON.stringify(x)) is a deep clone. So, flexibility: there are two options in my head for this. 1. An object passed to JSON.parse with options for how to deal with integers larger than Number can support. The current behaviour of misrepresenting them is the default. But other options could include converting to BigInts (or strings) if needed and always converting to BigInts (since they are non-interoperable currently). This approach allows the programmer to decide the behavior and plan for it in their code. 2. It seems like the already suggested JSONNumber object could offer the same flexibility and guarantees though. A `valueOf` that returns the misrepresented Number for interop with existing numbers. A `toString` that gives a well represented string conversion. (Im not 100% certain of the order these two functions are used in auto-casting. On mobile or else would check spec.) A `toBigInt` / `unwrap` (monad-ish terminology) to get the true value as and when the programmer wants. Hope these ideas seem reasonable. Scrutiny welcome. Rob J T Ede
robjtede at icloud.com (2018-07-30T11:47:29.092Z)
+1 on getting this sorted before stage 4 As people have said before, JSON already supports BigInts. We of course need to preserve backwards compatibility with JS and try not to break how other languages use JSON. I think the best way to satisfy everyone is to give ourselves some flexibility going forwards and JSONifying BigInts as strings doesn’t allow JSON to do what it *can* do. That and it breaks the idea that JSON.parse(JSON.stringify(x)) is a deep clone. So, flexibility: there are two options in my head for this. 1. An object passed to JSON.parse with options for how to deal with integers larger than Number can support. The current behaviour of misrepresenting them is the default. But other options could include converting to BigInts (or strings) if needed and always converting to BigInts (since they are non-interoperable currently). This approach allows the programmer to decide the behavior and plan for it in their code. 2. It seems like the already suggested JSONNumber object could offer the same flexibility and guarantees though. A `valueOf` that returns the misrepresented Number for interop with existing numbers. A `toString` that gives a well represented string conversion. (Im not 100% certain of the order these two functions are used in auto-casting. On mobile or else would check spec.) A `toBigInt` / `unwrap` (monad-ish terminology) to get the true value of and when the programmer wants. Hope these ideas seem reasonable. Scrutiny welcome. Rob J T Ede
robjtede at icloud.com (2018-07-30T11:46:46.721Z)
+1 on getting this sorted before stage 4 As people have said before, JSON already supports BigInts. We of course need to preserve backwards compatibility with JS and try not to break how other languages use JSON. I think the best way to satisfy everyone is to give ourselves some flexibility going forwards and JSONifying BigInts as strings doesn’t allow JSON to do what it *can* do. That and it breaks the idea that JSON.parse(JSON.stringify(x)) is a deep clone. So, flexibility: there are two options in my head for this. 1. An object passed to JSON.parse with options for how to deal with integers larger than Number can support. The current behaviour of misrepresenting them is the default. But other options could include converting to BigInts (or strings) if needed and always converting to BigInts (since they are non-interoperable currently). This approach allows the programmer to decide the behavior and plan for it in their code. 2. It seems like the already suggested JSONNumber object could offer the same flexibility and guarantees though. A `valueOf` that returns the misrepresented Number for interop with existing numbers. A `toString` that gives a well represented string conversion. (Im not 100% certain of the order these two functions are used in auto-casting. On mobile or else would check spec.) A `toBigInt` / `unwrap` (modad-ish terminology) to get the true value of and when the programmer wants. Hope these ideas seem reasonable. Scrutiny welcome. Rob J T Ede
robjtede at icloud.com (2018-07-30T11:46:28.161Z)
+1 on getting this sorted before stage 4 As people have said before, JSON already supports BigInts. We of course need to preserve backwards compatibility with JS and try not to break how other languages use JSON. I think the best way to satisfy everyone is to give ourselves some flexibility going forwards and JSONifying BigInts as strings doesn’t allow JSON to do what it *can* do. That and it breaks the idea that JSON.parse(JSON.stringify(x)) is a deep clone. So, flexibility: there are two options in my head for this. 1. An object passed to JSON.parse with options for how to deal with integers larger than Number can support. The current behaviour of misrepresenting them is the default. But other options could include converting to BigInts (or strings) if needed and always converting to BigInts (since they are non-interoperable currently). This approach allows the programmer to decide the behavior and plan for it in their code. 2. It seems like the already suggested JSONNumber object could offer the same flexibility and guarantees though. A `valueOf` that returns the misrepresented Number for interop with existing numbers. A `toString` that gives a well represented string conversion. (Im not 100% certain of the order these two functions are used in auto-casting*. On mobile or else would check spec.) A `toBigInt` / `unwrap` (modad-ish terminology) to get the true value of and when the programmer wants. Hope these ideas seem reasonable. Scrutiny welcome. Rob J T Ede