Theresa O'Connor <hober0@gmail.com> 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.