From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani
On Wed, May 30, 2018 at 5:31 AM Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com= > wrote:
> On Tue, May 29, 2018, 22:21 Philipp Stephani <p.stephani2@gmail.com>
wrote:
>> Please don't add global state to json.c. It's a low-level = library that
shouldn't rely on global state (and global state should generally be
avoided in libraries). Not having global state was one of my explicit
design goals for json.c
> Well, it's not really "global state" in the sense I beli= eve you're
talking about, because no part of the library is maintaining any state in global variables -- it's read-only from json.c.
I think the objection to global state (or a global setting, as the case may=
be) can be illustrated with the following scenario.
* Consider two independent Elisp packages =E2=80=98foo=E2=80=99 and =E2=80= =98bar=E2=80=99, both of which
want to use the JSON library.
* =E2=80=98foo=E2=80=99 wants plists while =E2=80=98bar=E2=80=99 wants alis= ts.
* =E2=80=98foo=E2=80=99 has a hook. The user adds to that hook a function t= hat invokes
=E2=80=98bar=E2=80=99.
* Result (after ironing out all bugs related to shared state): Every call to the JSON library has to be wrapped in a (let ((json-serialize-use-plists=
=E2=80=A6)) =E2=80=A6), which is more cumbersome than just passing an argum= ent to a
function.