all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: 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:12:18 -0700 (PDT)	[thread overview]
Message-ID: <4054d683-e291-4512-b5c6-1b10997c0d02@default> (raw)
In-Reply-To: <CAArVCkRGeubLsJFNjdL_-6wD7Ww62boJ_j40DCb253CBJpXm6A@mail.gmail.com>

> > > 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.

An application can do anything it wants with JSON
data, of course.  In particular, it can if it wants
(but typically would not) depend on the order of
duplicate fields.



  reply	other threads:[~2017-05-28 22:12 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 [this message]
2017-05-28 22:44         ` Bruce V Chiarelli
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=4054d683-e291-4512-b5c6-1b10997c0d02@default \
    --to=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.