4 ms·
> He summarized the most upvoted posts from the last thread [1] really well. I feel like he glossed right past the objections to the biggest and (to my mind) m
by outsidetheparty 10y ago
> He summarized the most upvoted posts from the last thread [1] really well.
I feel like he glossed right past the objections to the biggest and (to my mind) most destructive proposed change, the commas-to-whitespace thing; in fact doubles down on it (let's just declare that commas are whitespace! That surely won't confuse anyone!)
- thymelord 10y agoI've written a few JSON parsers over the years that treat commas as whitespace. The grammar is simpler and the parser is faster as result. As long as one always emits standards-compliant JSON there's no problem. Had the JSON standard supported ECMAScript array holes [1,,,2,,3] this grammar shortcut would not have been possible. But luckily that's not the case.
- outsidetheparty 10y agoWell, that's the thing, though: sure, for machine parsing it really doesn't matter what you use as a delimiter. But the only reason to get rid of commas is to eliminate the trailing comma problem, which only occurs when hand-editing JSON. Replacing that with whitespace, or worse both whitespace and commas, would be a lot more prone to hand-editing errors, I think, than would the much less drastic change of allowing trailing commas. Or better still of just leaving JSON as is and letting people use a more robust protocol, if that fits their needs, or pre-parsing whatever special snowflake variations they want into standards-compliant JSON. I'm more or less in agreement with the commenter on his site who said > this entire proposal pretty much comes down to "I like JSON, but need more and am too lazy to write the extra 3 line wrapper to process type 'x'." I'd say no thanks. https://www.tbray.org/ongoing/When/201x/2016/08/20/Fixing-JSON#c1471881712.859312 https://www.tbray.org/ongoing/When/201x/2016/08/20/Fixing-JS...