From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Native vs Elisp JSON key serialisation Date: Sat, 5 Dec 2020 21:34:44 +0200 Message-ID: <54dc9b44-f2a9-484f-93c4-5fb73fb42ff7@yandex.ru> References: <87365bbj3m.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16946"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: Philipp Stephani To: "Basil L. Contovounesios" , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 05 20:36:03 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kldLe-0004DH-Hx for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Dec 2020 20:36:02 +0100 Original-Received: from localhost ([::1]:40352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kldLd-0007tW-Gb for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Dec 2020 14:36:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50952) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kldKV-0007QE-5n for emacs-devel@gnu.org; Sat, 05 Dec 2020 14:34:51 -0500 Original-Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]:41585) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kldKS-0007P8-MK for emacs-devel@gnu.org; Sat, 05 Dec 2020 14:34:50 -0500 Original-Received: by mail-ej1-x636.google.com with SMTP id ce23so9894802ejb.8 for ; Sat, 05 Dec 2020 11:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KAd3jTzSWPVOKjvEkDe1BfBvah4tpsG/jF2i3hwr0zs=; b=l39q1Qu0WufMC3GA2exCdsSLgqbg1VzO8cbN9a0gwmfg3afWAkRHpFxP690us9NfWJ NxmzhG1m/GGUzrmxslKTJScisGwcV7ZdLz0LbSgqUQDbv4Gojol1apPXnXYH6kvzKitI yM2eB/AqgaY57KFO0EZHTy5yfisr7hZSvXS1HYqEkbhk88IjWa8X0ckKn0xNNOHSxDcg p4b1l5+z1cdN6RHMXKsPUmMIZKvcz+CCHf7VwGxKn33peN9r49NCdc/sx8Y98EEwna3d k98IXXZCfEZPuDorEa4YJO+DpEBORe9l4qOVnBrPtx/uR86wfDBaWs9I2LyVk0iXsQQR KdJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:cc:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KAd3jTzSWPVOKjvEkDe1BfBvah4tpsG/jF2i3hwr0zs=; b=VhVKUeb/0CyVGt6yY2ijm3GwkQnLOHNinAOqibiSlTr5ugyqB1Bd+fRUXptgVbb0T6 AWxKf2LIBPL/L/juCB4ZOO+2A+FdmSCCYtrtA8HYbKsug9lwZaQsk/tKjjC9vQB2r+Ed w4P+GKT9klCHZIduJun8AHz9eChzOjw4G26Nq70BlbfbyJXhRwcTHFvJLVdZafZR54Ky 5ZkVb5JdYYVLmQqM0Y9JJ7Ish/dIYGn97hJdGmPofoTcJuY60AO5aEOZDKOpZldgrT94 2WLgWBnSO7QLvh/Cz8evRiYSlpNwB8FRXvYQThEaf+USRpzYVmZVEI5RwTPYzDPQdWIO tWsw== X-Gm-Message-State: AOAM5303pHFWvBCzP+ala5U8t/ixGE5Sc9KX2p0BDXLT6UD/qFB8DalO HQ5ns1sheJVWoqW9HDUb7wk= X-Google-Smtp-Source: ABdhPJymY+9mjReLzm1e/H0y0c1/2+hwRycYkq4Dat77NsWlpcYHbwj4m9Xk3o1zKPLeWUVVamw4vg== X-Received: by 2002:a17:906:1c8e:: with SMTP id g14mr12625988ejh.5.1607196886531; Sat, 05 Dec 2020 11:34:46 -0800 (PST) Original-Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id b9sm5862886eju.8.2020.12.05.11.34.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 11:34:45 -0800 (PST) In-Reply-To: <87365bbj3m.fsf@tcd.ie> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::636; envelope-from=raaahh@gmail.com; helo=mail-ej1-x636.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:260386 Archived-At: 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.