4 ms·
"Why would you care what order we were sending the name value pairs for this?" The article makes it sound like it's somehow IBM's fault. However, questions abou
by al_form2000 7y ago
"Why would you care what order we were sending the name value pairs for this?" The article makes it sound like it's somehow IBM's fault. However, questions about preserving order in hashes/associative arrays/maps/whatchamacallit span at least thirty years. Some applications of the format even demand it (e.g. ansible uses YAML - a superset of JSON - or even straight JSON for it playbooks; emitting them out of order is not an option).
Every time the issue surfaces it elicits a large amount of eye rolling among the cognoscenti. However, I'm a firm believer in the idea that recurring demands from the user base need to be addressed, rather then mocked. The coding community appears to me notably tone deaf on this.
'Course anybody can use <insert suitable technique> to send a JSON map in the desired order, except the parser on the other hand will blissfully disregard it. Or you can devise any ordered solution on both ends, which will leave you outside of the accepted standard and open you up to the situation described in the article (where the requirement may well have been frivolous).
I can remember very few - if any - instances of somebody implying that the standard should somehow make room for this kind of scenarios. The standard reply was "use a different format" or "change the requirement". (Somehow remembers me of people asking what can one do to have whitespace-preserving XML, and at least one amusing story about that)
- viraptor 7y agoJson has a perfectly fine order preserving key-value map: [["Key1", "value1"], ["key2", ... You just need to deserialise it into a specific collection on the receiver. It's within standards and there are no weird parser issues.
- al_form2000 7y agoThat's a way. A way that, IMHO, vastly diminishes its expressive power on the reader's side, which I do not consider a very good thing. Most solutions to the issue are of this nature. Consider serialized JSON already has a natural ordering, which is thrown away for some reason (probably parsing convenience).
- viraptor 7y ago> which is thrown away for some reason (probably parsing convenience). It's got nothing to do with parsing. The json comes from JavaScript syntax, where objects represent unordered mapping. Json naturally does the same. If you want expressive power for reading, json is very poor in comparison to pretty much everything else. Just use it for simple serialisation.
- al_form2000 7y agoGranted, it came from there, but that was back in the days of map=eval(json) and they're gone. There is nothing in json the format (as opposed to json the language construct) to impose the unordered behavior.(Or, for that matters, the 'no comments' bit).
- adrianmsmith 7y ago> There is nothing in json the format [..] to impose the unordered behavior That's not true. The spec at http://www.json.org/ http://www.json.org/ says "An object is an unordered set of name/value pairs".
- al_form2000 7y agoYes, that's in the specs. But what I meant is that there is nothing intrinsic to the format demanding unordered behavior.
- josephg 7y agoI hear that. But also, JSON does not have a canonical serialisation. Other than object key ordering, strings have multiple equivalent formats (direct Unicode characters, \u00xx, \xXX, etc). Numbers have exponential form (1e2 is the same as 100). And white space is ignored - [2] and [ 2 ] and [2\n] are all equivalent. If your application expects JSON input to conform to one particular set of decision points here, that’s fine and useful but you’re not using JSON anymore. You’re using a JSON-compatible subset. Document that new thing you’ve made and stop calling it JSON; because it’s not.
- al_form2000 7y agoAgree. Except that the sheer number of questions about this spell "missed use case" - to my eyes at least. Sort of like the "How do I push a local branch to remote?" question in GITland.