Re: two json.el bugs

[Bruce V Chiarelli]

Drew Adams <address@hidden> writes:

>> > > 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.)
>> >   ^^^^^^^^^^^^^^^^^^^^^^^^^
>> >
>> > If you're talking about JSON objects then no, no particular
>> > meaning or behavior is defined for duplicate fields (keys)
>> > in a JSON object.
>> >
>> > A given application that handles JSON object is free to
>> > act as you say.  And it is free to act otherwise.
>>
>> Please see Theresa's initial post why this matters.
>
> It is generally good to preserve the order.  With
> that general intention I agree.
>
> What's not true is that "in JSON the last one wins"
> when there are duplicates.  JSON itself imposes no
> such semantics.
>
> And I question mention of "the standard JS
> implementation".  No such thing, AFAIK.

ECMA 404 doesn't specify anything about duplicate keys, but the JSON
parser behavior required by Section 24.3 of ECMA 262 does indeed. It's
not an implementation of course, but it does dictate how compliant JS
implementations should handle JSON.

>From the end of listing 24.3.1.1: "In the case where there are
duplicate name Strings within an object, lexically preceeding values
for the same key shall be overwritten"
(https://www.ecma-international.org/ecma-262/7.0/index.html#sec-internalizejsonproperty).

It could be argued that Emacs does not need to have (or pretend to
have) a 262-conforming parser. After all, it's not a JS
interpreter. But as Tess mentioned, this particular point creates
interoperability issues with conforming interpreters.

---
Bruce V. Chiarelli