On 2018-07-28 21:21, Ranando King wrote:
What I meant by complete is that if the value isn't an ES Number, isn't a boolean, and isn't null, it will have a string representation, or a binary representation that can be encoded as a string using base64. By using a dataUri for those cases, we can create a consistent library to handle those issues automatically, and without guesswork (no magic). If such a utility API became a standard in ES, other languages would be far more likely to adopt the standardized notation that would be provided.
As I have tried (apparently in vain) to describe, the other languages already have solutions for BigInt (and much more), which the respectively authors consider both sufficient and good. ES6 is pretty late in the game and therefore rather have to adapt itself to the other players. These are the options: https://esdiscuss.org/topic/json-support-for-bigint-in-chrome-v8#content-30 - "Conservative" works right out of the box (although in a somewhat inelegant way). It is backward compatible with many existing ES and non-ES JSON based applications. - "RFC8259" support would require changes to the ES6 JSON object. For parsing (`JSON.parse2()`), a `JSONNumber` object as proposed by Michael Theriot seems like a candidate. I have limited faith in extending the (for general purpose information interchange) already pretty deficient JSON type scheme; state-of-the-art applications check indata anyway making explicit type information redundant. Anders
On Sat, Jul 28, 2018 at 12:03 PM Michael Theriot <michael.lee.ther...@gmail.com <mailto:michael.lee.ther...@gmail.com>> wrote: 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 <d3c...@gmail.com <mailto:d3c...@gmail.com>> wrote: On Sat, Jul 28, 2018 at 6:57 AM Michael Theriot <michael.lee.ther...@gmail.com <mailto:michael.lee.ther...@gmail.com>> 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 <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 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 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 <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
