On 2018-03-19 08:23, Michał Wadas wrote:
It's workaround.
I forgot to mention that if you overload the "Number" type with int64's, BigNum's, BigInt's etc. you will need a mapping scheme so that the parser knows what to look for and create. OTOH, mapping from a string literal using the replacer already have what it takes. Right, this won't work for the people who had to write their own JSON tools due to limitations in "Number". Anders
JSON.parse can't properly parse valid JSON subset. ZIP codes are not part of JSON specification, arbitrary precision numbers are (and JSONs with 64-bit ints are widely used). Modyfing schema is possible only if you control it and control all of its consumers. BigInt proposal already cover serialisation part. On Mon, 19 Mar 2018, 08:11 Anders Rundgren, <[email protected] <mailto:[email protected]>> wrote: On 2018-03-19 07:32, Michał Wadas wrote: > Yeah, there are workarounds for passing bigints. > > Unfortunately, it's workaround, and it doesn't solve the problem - > certain valid JSONs can't be properly used in ECMAScript without writing JSON parser in user land. Hi Michal, I wouldn't call it a workaround. The idea that there must be a native data type in a message format for each data type you can come up with has huge real-world limitations. Physical address descriptors (street, zip, state, etc), don't have native JSON counterpart either to take a fully valid example from another application area. Using an external (with respect to the parser), mapping schema [1,2] addresses these problems in a fully universal and extensible manner. toJSON seems to do a good job in the other direction. The importance of JSON "Number" is exaggerated. In the systems I work with (Payments), you hardly find a single instance of "Number". No, it doesn't even work for expressing money! Anders 1] Ultra simple/manual: new BigNum(obj.sizeOfTheUniverseInCubicMeters); 2] Sophisticated: JSON.parseWithSchema(schema, jsonData); > > On Mon, 19 Mar 2018, 03:33 Anders Rundgren, <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: > > On 2018-03-19 02:37, Anders Rundgren wrote: > > On 2018-03-19 02:33, Michał Wadas wrote: > >> Fact: JSON allows arbitrary precision numbers. > >> Problem: JavaScript is unable to express these numbers. > >> > >> Proposed solution: introduce JSON.safeParse. This method will work as JSON.parse, but throwing on values that can't be accurately represented by IEEE 754 64-bit float. > >> > >> Alternative: allow user to specify number class - eg. by adding options object with optional method "parseNumber", overwriting default behaviour of using builtin number type. > >> > >> Any thoughts on this? > > > > Yes, it is a SUPERBAD idea. > > Pardon my unnecessary dismissive response. A more constructive response would be: > > This is "approximately" the de-facto standard for dealing with BigNums and tons of other non-standard types. > > var obj = JSON.parse("JSON formatted data"); > var val = new BigNum(obj.sizeOfTheUniverseInCubicMeters); > > JSON on the wire: > { > "sizeOfTheUniverseInCubicMeters": "3.45e+445454545454545776767676676" > } > > When TC-39 introduces BigNums in ES, this is the most likely way they will address this particular aspect. > > Anders > > > > > > Anders > > > >> > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
