On 2018-03-19 08:23, Michał Wadas wrote:
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).
Well, you have an comrade at Google (Mike Samuels) who also believe that making
JSON.parse incompatible with Java, .NET etc. is a good idea although it suffice
putting such values within a pair of quotes.
Also worth a read: https://tools.ietf.org/html/rfc7493#section-2.2
Anders
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, <anders.rundgren....@gmail.com
<mailto:anders.rundgren....@gmail.com>> 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, <anders.rundgren....@gmail.com
<mailto:anders.rundgren....@gmail.com> <mailto:anders.rundgren....@gmail.com
<mailto:anders.rundgren....@gmail.com>>> 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
> >> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
<mailto: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
