Hello,
On , Mattias Andrée wrote:
> Wouldn't it just complicate matters if you needed to specify whether a
> number is an integer or a real value;
Could you not just consider sequence of [0-9]+ to be an integer and
anything with other characters either invalid or float? Not sure, I'm in
no means a parser expert, so I might be missing something fundamental
here.
> Additionally, I think you would want to support for arbitrary
> precision. Again, the software can just check if arbitrary precision
> is required, no need to complicate the syntax.
Agreed, arbitrary precision would be nice, and currently is probably
done via strings if it's needed. But not sure if it's something you want
to have in the standard though as a separate type. Passing them via
string is probably good enough for specialized applications that do need
them.
> What should a library do with parsed numbers that are too large or too
> precise?
Report an error and provide flag to do best-possible parsing if user
wants the number anyway knowing it will not be precise. Not do a silent
guesstimate.
Basically, I think the fact that following returns false is stupid:
+ $ ruby -rjson -e 'puts({ num: (?9 * 100).to_i }.to_json)' \
| node -p 'var fs = require("fs");
JSON.stringify(JSON.parse(fs.readFileSync(0, "utf-8")));' \
| ruby -rjson -e 'puts (?9 * 100).to_i == JSON.parse(STDIN.read)["num"]'
false
That means that despite all libraries in the chain fully implementing
the JSON standard, not silently corrupting the data during the
round-trip is not guaranteed.
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Received on Sat Jun 15 2019 - 22:11:13 CEST