From: Dmitry Gutov <dgutov@yandex.ru>
To: "Basil L. Contovounesios" <contovob@tcd.ie>, emacs-devel@gnu.org
Cc: Philipp Stephani <phst@google.com>
Subject: Re: Native vs Elisp JSON key serialisation
Date: Sat, 5 Dec 2020 21:34:44 +0200 [thread overview]
Message-ID: <54dc9b44-f2a9-484f-93c4-5fb73fb42ff7@yandex.ru> (raw)
In-Reply-To: <87365bbj3m.fsf@tcd.ie>
On 28.07.2020 21:16, Basil L. Contovounesios wrote:
> While looking at bug#42545, I noticed some inconsistencies in object key
> serialisation between json-encode and json-serialize.
>
> When serialising hash tables:
> - json-encode translates the keys 'foo, :foo, and "foo" to "foo"
> - json-serialize translates "foo" to "foo"
> (and rejects symbols as keys)
>
> I don't have a problem with this; it makes sense to me that json.c is
> stricter, and json.el is older so has more backward compatibility to
> maintain. In other words, the two implementations are sufficiently
> consistent IMO.
IDK, we might add those, sooner or later. Not sure why we would
explicitly want to reject symbols as keys. But perhaps the author just
wanted to avoid the decision on how to translate them. ;-)
/Cc'ing Philipp here.
> When serialising alists:
> - json-encode translates 'foo, :foo, and "foo" to "foo"
> - json-serialize translates 'foo to "foo", and :foo to ":foo"
> (and rejects strings as keys)
>
> Here the two implementations are inconsistent. Should the older
> json-encode also translate :foo to ":foo", or should the newer and more
> prominently (in the Elisp manual) documented json-serialize translate
> :foo to "foo"?
The latter, probably?
The older package might be not as well documented, but it should have
better compatibility with existing code. Although, given that we haven't
seen any reports regarding that (right?), the choice in the other
direction is conceivable too.
> When serialising plists:
> - json-encode translates :foo to "foo" (and interprets 'foo and "foo" as
> starting an array rather than associative object)
> - json-serialize translates 'foo and :foo to "foo"
> (and rejects strings as keys)
>
> Here the two implementations are again inconsistent. Should json-encode
> also accept plists with non-keyword symbols as keys, or should
> json-serialize accept only keywords as keys?
Seems like json-serialize is inconsistent with itself here (:foo turns
into "foo", unlike the previous case).
I think using keyword symbols to distinguish plists is a clever idea,
and json-encode could adopt it too (even despite backward compatibility
concerns). But that case maps :foo to "foo", so json-serialize and
json-encode should do that in other cases, too.
prev parent reply other threads:[~2020-12-05 19:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 18:16 Native vs Elisp JSON key serialisation Basil L. Contovounesios
2020-12-05 19:34 ` Dmitry Gutov [this message]
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=54dc9b44-f2a9-484f-93c4-5fb73fb42ff7@yandex.ru \
--to=dgutov@yandex.ru \
--cc=contovob@tcd.ie \
--cc=emacs-devel@gnu.org \
--cc=phst@google.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.