←back to thread

Fixing JSON

(www.tbray.org)
139 points robin_reala | 3 comments | 20 Aug 16 18:08 UTC | HN request time: 0.659s | source
Show context
_greim_ ◴[20 Aug 16 18:35 UTC] No.12327784[source]▶
With the exception of trailing commas, all these things would break the fact that JSON is a subset of JavaScript. Breaking that would cause a lot more problems than it solves. It's just that the minor problems you have to live with seem worse than the major problems you don't.
replies(1): >>12327801 #
wtetzner ◴[20 Aug 16 18:38 UTC] No.12327801[source]▶
What value is there in having JSON be a subset of JavaScript? In fact, it would be a good idea to make it not be a subset of JS, because that would prevent people from evaling it.
replies(6): >>12327847 #>>12327856 #>>12327894 #>>12327900 #>>12327926 #>>12328431 #
Franciscouzo ◴[20 Aug 16 19:13 UTC] No.12327926[source]▶
To be pedant, JSON is NOT a subset of Javascript [1], using U+2028 or U+2029 inside a JSON string is perfectly valid, but is not in Javascript.

[1] http://timelessrepo.com/json-isnt-a-javascript-subset

replies(1): >>12327951 #
colanderman ◴[20 Aug 16 19:21 UTC] No.12327951[source]▶
Don't forget also that large integers are perfectly valid JSON (which imposes no semantics on numbers except that they are representable in decimal), but do not survive translation to JavaScript, which has only IEEE floats.
replies(1): >>12328569 #
1. querulous ◴[20 Aug 16 22:39 UTC] No.12328569[source]▶
the loose specifications of json types is my biggest gripe as the maintainer of a json library. if json mandated that all strings be representable as utf8 byte sequences (after resolving escapes) and that all numbers be representable as ieee 754 doubles it would be much easier to provide sane and consistent defaults for encoding and decoding. as it is all implementations have to make explicit choices as to how to handle things like escaped strings that represent invalid utf8 byte sequences (like `"\uD800"`) or numbers unrepresentable with a double (like `1e400`). there isn't even any sort of consensus on how to decode a number representable as an integer. some implementations produce integers, others floats
replies(1): >>12328663 #
2. colanderman ◴[20 Aug 16 23:01 UTC] No.12328663[source]▶
Isn't the simple solution to decode e.g. a number as a special type, say JSON_number, which can fully represent what's on the wire? Then the user can access the number via one of a number of conversion functions depending on the native data type he/she wants (e.g. JSON_number_to_float). Is there really a huge benefit to eagerly performing this conversion?
replies(1): >>12328920 #
3. querulous ◴[21 Aug 16 00:28 UTC] No.12328920[source]▶
that's a simple solution yes, but also a verbose one. the primary appeal of json as a data exchange format is that it maps to ubiquitous types like objects/hashmaps, arrays, strings and numbers. if you need to hint the decoder or manually perform conversions it loses a lot of appeal as a user