Native vs Elisp JSON key serialisation

Native vs Elisp JSON key serialisation

[Basil L. Contovounesios]

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.

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"?

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?

In both cases, I'm inclined to change json-encode to be more consistent
with json-serialize as the more authoritative of the two.  Either way, I
think the two implementations should be as consistent and thus
interchangeable as possible.  WDYT?

-- 
Basil

Re: Native vs Elisp JSON key serialisation

[Dmitry Gutov]

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.