From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: two json.el bugs Date: Sat, 27 May 2017 13:48:20 +0000 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113ce8ca998df4055081b56e" X-Trace: blaine.gmane.org 1495892920 598 195.159.176.226 (27 May 2017 13:48:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 May 2017 13:48:40 +0000 (UTC) To: "Theresa O'Connor" , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 27 15:48:36 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dEc54-0008Se-Cu for ged-emacs-devel@m.gmane.org; Sat, 27 May 2017 15:48:34 +0200 Original-Received: from localhost ([::1]:40870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEc59-0006r4-Tf for ged-emacs-devel@m.gmane.org; Sat, 27 May 2017 09:48:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEc53-0006qy-Aq for emacs-devel@gnu.org; Sat, 27 May 2017 09:48:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dEc52-0000Cw-Dz for emacs-devel@gnu.org; Sat, 27 May 2017 09:48:33 -0400 Original-Received: from mail-oi0-x229.google.com ([2607:f8b0:4003:c06::229]:33456) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dEc52-0000Cq-7a for emacs-devel@gnu.org; Sat, 27 May 2017 09:48:32 -0400 Original-Received: by mail-oi0-x229.google.com with SMTP id w10so40766400oif.0 for ; Sat, 27 May 2017 06:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vvJmTiaF14VUsHVqdKCVkzEuS5wbWNIHR0tYKzdyP3s=; b=I43BwpuS7ZZbgW7qqYFbAYbrBiUnJA94yWG4b2bQk31zE4C3b80WzEqwZ4Ghsv9xhi QLK2O6ALVMOfp/uGOPv9bYnUrxaOAx9xtcr1b7TlAB2mT/hH71blf6Gq/ahCW/wTh06U zgHroHABi0D23sld5m3tOuJwLqtLq9kQDyJSa8sXqwntxidkvZSuaj8SCLTBnXolmXmW CNFs163+3Atw77xh2ianGKh+Qo6ErpuF4UHrRhnML9cCvqDs+g32+e+QDMuCm2990G6b IqxR+2oy2ASjuwPR4WEITosb3IyU6I4L7waHDyPaRbzZLE//bS/r+LQ2w3PkSMCW+z0X m0kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vvJmTiaF14VUsHVqdKCVkzEuS5wbWNIHR0tYKzdyP3s=; b=IZqRi8WoEJ97cf/iU6AyTKfwl8PRCV+IQJIhEf/aoA24I59DHt1K7Tb4oSe5eRL6Oh HIocU5n3FO1HnpQjm6dq25vC41MUzP9sLJZTam4H65rp1aiy7CmpLaGe7glUK2nlwCmb Vb22D0sY9yXA+A27cxUCT4ZMD5e2E0OYDLPqPQ0uVS2KRQvNesG7UPaM3VKFdkGxhZ8K RmTAHZvQQZwOqHCTazaYQF6PRIKNgjL6SEJEy9xTk/mw/mdJFUU8nU+bJ6psuvUM6q/a q+SZ+HyF1KIQrOSZfOEFm61pA3Vpz9aTFV98vZc7YOX2IflKF2yM8mqdB6F34lCUCt6k P7JA== X-Gm-Message-State: AODbwcCM4smtSqsYAJDrLY6SxFDZK10znMID7pOZNkLHOip9yZxKXRe6 2jN8c3dVGLsX52YLPhecBgmW8Ye1yQ== X-Received: by 10.202.235.68 with SMTP id j65mr2904043oih.2.1495892911294; Sat, 27 May 2017 06:48:31 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:215267 Archived-At: --001a113ce8ca998df4055081b56e Content-Type: text/plain; charset="UTF-8" Theresa O'Connor 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. --001a113ce8ca998df4055081b56e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Theres= a O'Connor <hober0@gmail.com= > schrieb am Fr., 5. Mai 2017 um 19:52=C2=A0Uhr:

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.

{
=C2=A0 "foo": "the foo property is used for blah blah blah.&= quot;,
=C2=A0 "foo": 4
}

Last key should always win when reading, and order needs to be
preserved when serializing so that these "comments" can be genera= ted.
This is a fairly serious interoperability issue.


This one needs to be designed carefull= y. We can't simply serialize/desterialize alists in key order because t= he order is reversed in Emacs. (In Emacs alists, if there are duplicates, t= he first one wins, in JSON the last one wins.)
So maybe we should= just reverse the order on serializing? Unfortunately this means that seria= lizing and then deserializing is no longer a round-trip. Should we then als= o reverse the order on deserializing? If there are duplicates it would stil= l not be a round-trip, but at least would allow the "comment" syn= tax.
Alternatively, we might just throw an error when encounterin= g duplicates. =C2=A0
--001a113ce8ca998df4055081b56e--