Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECMA-404: The JSON Data Interchange Format [pdf]

ecma-international.org

Post reply on HN
Print view View original

131–140 of 199 posts

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#131

Post by Zikes »

TeeWEE wrote: post #126
Jare wrote: post #8

My faint hopes for trailing comma support are now crushed.

Trailing comma's, really?? Its is so fucking ugly and inconsistent. Either ALWAYS have traling commas, or never have it. And since the meaning of a comma is separate two items, a trailing comma makes no semantical sense, the only reason you want it because A) youre lazy B) you dont know howto properly serialize to json (youre doing string manipulation probably C) you never heard about the .join function D) you dont k…

A) Wat.

B) Somebody's gotta write those serialization libraries, and they probably do a fair amount of string manipulation to do so.

C) You can't .join data streams without buffering, which defeats the purpose.

D) Adding commas on a preceding line every time you add a new item to a list can pollute diffs.

E) Trailing commas are syntactically correct in ECMAScript 6, and supported by a fair few other languages.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#132

Post by Zikes »

mercurial wrote: post #123
optymizer wrote: post #115

Earlier quoted context omitted.

no, that's not what json for. JSON is for exchange data between machines. We already have data interchange formats for humans, we call those 'languages'.

Yes, yes. And we could also have everything as binary. Now, UNIX people decided long ago to use plain text to communicate between processes, mostly because it's infinitely easier to read - and makes it possible to edit by hand if you need to. Have to interface with a REST API which consumes JSON and you want to do some testing? Open your text editor anywhere curl is installed, and you're done. That's pretty damn conv…

Also becoming commonplace as a config file format.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#133

Post by chimeracoder »

nknighthb wrote: post #77
chimeracoder wrote: post #63

Earlier quoted context omitted.

Interesting. It says they're the same thing, but then the two characters listed on the page (the regular backslash and the Unicode variant) are rendered noticeably differently. I can't imagine why they changed the name, given that the forward slash and the solidus are not interchangeable. http://www.fileformat.info/info/unicode/char/5c/index.htm

Look at the HTML. The "unicode variant" is rendered differently because the code tells the browser to render it differently, not because it's a different character. \

Ah, thanks. I was on my phone and didn't think to check the source.

EDIT: Actually, this explanation is enlightening: http://en.wikipedia.org/wiki/Slash_(punctuation)#Encoding

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#134

Post by mercurial »

Zikes wrote: post #132
mercurial wrote: post #123

Earlier quoted context omitted.

Yes, yes. And we could also have everything as binary. Now, UNIX people decided long ago to use plain text to communicate between processes, mostly because it's infinitely easier to read - and makes it possible to edit by hand if you need to. Have to interface with a REST API which consumes JSON and you want to do some testing? Open your text editor anywhere curl is installed, and you're done. That's pretty damn conv…

Also becoming commonplace as a config file format.

Yeah. On the other hand, I find YAML much better for this kind of thing. JSON is readable and writable by hand, but it's not terribly nice.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#135

Post by mercurial »

lttlrck wrote: post #128
mercurial wrote: post #119

Earlier quoted context omitted.

> It simplifies generating JSON, since you don't need a special case for the last item In which language can't you do array.join(",")? You can even do that in Java with one of the myriad of string libraries. I haven't hand-coded joins since (at least) six or seven years.

Join doesn't help to stream to JSON from a database cursor. Unless you buffer the response first which is pretty horrid.

Fair point.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#136

Post by Zikes »

mercurial wrote: post #134
Zikes wrote: post #132

Earlier quoted context omitted.

Also becoming commonplace as a config file format.

Yeah. On the other hand, I find YAML much better for this kind of thing. JSON is readable and writable by hand, but it's not terribly nice.

No doubt they both have their benefits, however in an environment particularly suited for working with JSON, like node.js, the additional overhead of a YAML (or other) parser may not be desirable.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#138

Post by curveship »

I really (really really) wish they'd added a way to represent dates. Dates were left out of the original JSON spec since javascript doesn't define a syntax for date literals. You have to execute the Date() constructor to make them. Since JSON was supposed to be a subset of non-executing javascript, dates were excluded from JSON.

That left serialization to a string as the only way to transfer dates. But since there's no specification for the format to use, cross-browser date parsing is a mess (see http://dygraphs.com/date-formats.html ). JSON + dates = sadness.

The non-executing constraint on JSON was a good idea in its early days, when eval was the most common way to parse JSON, but now that there are dedicated parsers for all environments, it's not as much a priority. But we're still stuck with kludgy workarounds for the lack of native date support in JSON.

If there's still concern about using the Date constructor, the spec could require that the date be prefixed to avoid execution: "0 || new Date(...)". Real parsers would extract the date correctly, eval would just return 0.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#139

Post by angersock »

duaneb wrote: post #100
angersock wrote: post #49

Earlier quoted context omitted.

Not really... just add a "comment" key and then ignore it when processing.

Yes, that solution OBVIOUSLY removes the need to spend an extra minute adding comments to the spec. Also, I hope, trailing commas and binary types.

Shoving binary into JSON is rather silly--base 64 encode it, or consider using a binary format better suited to your need.

As for adding comments to the spec--again, the idea is to prevent shadow information showing up that isn't obvious to a conformant parser.

If you give people the ability to smuggle data in comments, that's exactly what they'll do. At least this way people know that what they're doing isn't "to spec" and that their sneaky parsers are not following the rules.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#140

Post by bcj »

TeeWEE wrote: post #126
Jare wrote: post #8

My faint hopes for trailing comma support are now crushed.

Trailing comma's, really?? Its is so fucking ugly and inconsistent. Either ALWAYS have traling commas, or never have it. And since the meaning of a comma is separate two items, a trailing comma makes no semantical sense, the only reason you want it because A) youre lazy B) you dont know howto properly serialize to json (youre doing string manipulation probably C) you never heard about the .join function D) you dont k…

Trailing commas reduce cognitive load. I don't need to consider whether an element I'm adding is the last item in a set; there isn't an edge case. Also, I can more quickly scan a DIFF and see the change in a file.
Post reply on HN