It's workaround. 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]> 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]>> > 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]> > > >> https://mail.mozilla.org/listinfo/es-discuss > > >> > > > > > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
