←back to thread

Fixing JSON

(www.tbray.org)
139 points robin_reala | 2 comments | 20 Aug 16 18:08 UTC | HN request time: 0.506s | source
Show context
pluma ◴[21 Aug 16 07:50 UTC] No.12329905[source]▶
In my opinion there are five problems with JSON in practice:

1. Trailing commas should be allowed. This would fix the entire comma ordeal the author is complaining about without introducing awkward whitespace logic.

2. Date time values should be a distinct type using the format of JS's Date.prototype.toISOString method. Had this been in the language when JSON was originally defined I'm sure it'd already be in JSON.

3. There should be a way to represent Infinity (for IEEE 754 compatibility) and possibly NaN.

4. Comments would be nice because JSON is often used for configuration and documenting JSON snippets can get awkward without them.

5. There's no real way to represent binary data other than base64 encoded strings. It would be nice if there was at least some hex format (e.g. `"blob": <dead beef cafe babe>` with optional spaces for readability) but I can see why some people might be opposed to the idea of adding this to the language

replies(4): >>12330188 #>>12330375 #>>12330613 #>>12330688 #
1. legulere ◴[21 Aug 16 12:32 UTC] No.12330688[source]▶
I'm a bit wary of the second and fifth one. You could add an arbitrary amount of datatypes. Also I think the common argument against comments makes much sense: they could get abused easily for parsing directives etc. JSON isn't that nice for configuration files anyway IMO.

I would actually take away a feature of JSON: Unicode escaping. It's not needed anyway and astral plane characters being encoded as surrogate pairs is an added complexity for encoders/decoders. The selection of escape codes for control characters also is rather arbitrary.

replies(1): >>12330926 #
2. dap ◴[21 Aug 16 13:58 UTC] No.12330926[source]▶
The argument about abusing comments with parser directives is totally bogus. You can create parser directives with extra field names too! Worse, people create comments anyway using fields like "//" -- but they're much crappier than real comments, since they have to be a valid string value. We gave up a solution to a real problem in favor of a bogus solution to a theoretical problem.