On 17/12/2014, at 9:59 pm, Wojtek Narczyński
On 17.12.2014 00:12, Richard A. O'Keefe wrote:
So if you depend on the order of the name/value pairs in a JSON object, you doing something surpassing strange and risky. All I wanted to do was to keep the order of key-value pairs in accordance with the order of fields in their corresponding haskell records, during serialization. I guess that would be okay.
At some point, you convert an internal value to a “JSON” form, x. You hand that over to some other JSON-handling software, and eventually get the “same” value back, x’. The other JSON-handling software could be something as simple as [StdIn skipSeparators] whileFalse: [ StdOut printJson: StdIn nextJson; cr]. Now x’ may *legitimately* be different from x, both in the amount and location of white space, the presence or absence of leading and trailing zeros in numbers, the use or non-use of \u escapes in strings, *and the order of key/value pairs in objects*. So if your program depends on the order of key/value pairs, you cannot trust JSON-handling software you have not writtern yourself to preserve your extra semantics. That’s what I mean by “risky”. For reasons having to to with compressibility, I’d probably use {“fields” : [“f1”,..,”fn”], “values” : [v1, .., vn ] } if I wanted safe interoperability with 3rd-party JSON support.