41–50 of 251 posts
Earlier quoted context omitted.
it's true JS doesn't support this, and it's also true that any JSON that supported it would therefore no longer be _JavaScript_ object notation. However, it's equally true that a better language and object notation would support non-string scalar keys.
I can see why you want non-string scalar keys. In general, I do too. (I'm writing a data language that has them.) However, I don't think it is useful to prod JSON (or a variant) to go in this direction.
Earlier quoted context omitted.
https://en.wiktionary.org/wiki/RTFA
I'm aware, thanks. I wanted to see if CameronNemo would spell it out. I'd like to point out the HN Guidelines: https://news.ycombinator.com/newsguidelines.html > Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." Even putting aside what "F" stands for, this means that comments like TFA or RTFA are not in the spiri…
Earlier quoted context omitted.
I wish JSON supported comments, but I don’t really understand your criticism. You say: > Without a standard format for comments, you have no reason whatsoever to expect the ad-hoc comments in a JSON file made by anyone who isn't you to be styled like JavaScript comments. But, since comments are not supported in JSON, you can expect JSON from external sources to contain no comments whatsoever. That’s precisely Crockfo…
I can't believe that anyone who has ever wanted to comment a package.json file could think Crockford's argument is anything but nonsense. The problem is these files are both edited by humans, and by a plethora of tools. Without a standard comment format, it's been a nightmare trying to comment package.json file in a way that doesn't break something in the NPM/Node ecosystem.
Earlier quoted context omitted.
https://en.wiktionary.org/wiki/RTFA
I'm aware, thanks. I wanted to see if CameronNemo would spell it out. I'd like to point out the HN Guidelines: https://news.ycombinator.com/newsguidelines.html > Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." Even putting aside what "F" stands for, this means that comments like TFA or RTFA are not in the spiri…
Earlier quoted context omitted.
I can see why you want non-string scalar keys. In general, I do too. (I'm writing a data language that has them.) However, I don't think it is useful to prod JSON (or a variant) to go in this direction.
Why not?
Been there, done that.
JSON became popular data format because it didn’t have all the overhead of comments and extensibility.
Earlier quoted context omitted.
Would you like to spell out what TFA means?
People use TFA (the fine/featured article) without malice here. I apologize that I did not convey my spirit adequately.
The term is very easily confused, to state the obvious.
In my opinion, I think it would be better to avoid it. I'm sorry if one negative meaning deprives people of the joy of using a nicer one, but such is the nature of language.
Earlier quoted context omitted.
it's usually a pretty bad idea to have a mutable object (the array) as a key. Though I guess if you consider it as a 'tuple' since when in json form it can't be modified I guess it'd be technically possible, though with some heavy caveats.
There’s no concept of mutability in JSON. A JSON parser could give you immutable arrays and maps if it wanted to.
If it's a map I'm a bit more unsure how you'd check to find the object (quickly). You're basically getting into the how to store a struct/class as a map key. Either way its a bit more involved than just having json parser return an immutable array and map, and the more I think about it the more edges cases there are.
There’s already JSON with comments, called XML. It’s Extensible! Been there, done that. JSON became popular data format because it didn’t have all the overhead of comments and extensibility.
Earlier quoted context omitted.
It's going to have to be a different mode and mimetype because this format would break all kinds of parsers. I wish something would done in this area relatively soon though because JS has added a number of features that would make a new JSON much nicer like multi-line strings and BigInts. I think JSON + comments, commas, template literals, BigInt, NaN, Infinity, and BigDecimals (if/when those land in JS) would be ver…
JSON doesn’t specify its numeric types: the mapping of a string of digits to concrete numeric types is implementation-defined: so, JSON doesn’t need specific syntax for BigInts or arbitrary-precision decimals.