From: Bruce V Chiarelli <mano155@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: Philipp Stephani <p.stephani2@gmail.com>,
Theresa O'Connor <hober0@gmail.com>,
emacs-devel@gnu.org
Subject: Re: two json.el bugs
Date: Sun, 28 May 2017 15:44:04 -0700 [thread overview]
Message-ID: <871sr87gaz.fsf@topd0g> (raw)
In-Reply-To: <4054d683-e291-4512-b5c6-1b10997c0d02@default>
Drew Adams <drew.adams@oracle.com> 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
next prev parent reply other threads:[~2017-05-28 22:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 17:51 two json.el bugs Theresa O'Connor
2017-05-05 18:44 ` Yuri Khan
2017-05-05 19:25 ` Drew Adams
2017-05-20 15:51 ` [PATCH] Fix definition of whitespace in JSON Philipp Stephani
2017-05-20 17:28 ` Dmitry Gutov
2017-05-21 21:03 ` Philipp Stephani
2017-05-27 13:32 ` two json.el bugs Philipp Stephani
2017-05-27 13:48 ` Philipp Stephani
2017-05-28 1:30 ` Drew Adams
2017-05-28 18:47 ` Philipp Stephani
2017-05-28 22:12 ` Drew Adams
2017-05-28 22:44 ` Bruce V Chiarelli [this message]
2017-05-29 0:42 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871sr87gaz.fsf@topd0g \
--to=mano155@gmail.com \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=hober0@gmail.com \
--cc=p.stephani2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.