Theresa O'Connor <
address@hidden> schrieb am Fr., 5. Mai 2017 um 19:52 Uhr:
2. Order of key-value pairs is not explicitly preserved in either the
reader or the serializer, and if there are duplicate keys, either the
first or the last wins depending on a number of factors. While json
objects are technically defined to be unordered (and therefore
json.el's current behavior is conforming), the standard JS
implementation preserves order and a convention has developed whereby
duplicate keys are used to provide "comments", e.g.
{
"foo": "the foo property is used for blah blah blah.",
"foo": 4
}
Last key should always win when reading, and order needs to be
preserved when serializing so that these "comments" can be generated.
This is a fairly serious interoperability issue.
This one needs to be designed carefully. We can't simply serialize/desterialize alists in key order because the order is reversed in Emacs. (In Emacs alists, if there are duplicates, the first one wins, in JSON the last one wins.)
So maybe we should just reverse the order on serializing? Unfortunately this means that serializing and then deserializing is no longer a round-trip. Should we then also reverse the order on deserializing? If there are duplicates it would still not be a round-trip, but at least would allow the "comment" syntax.
Alternatively, we might just throw an error when encountering duplicates.