From: Philipp Stephani <p.stephani2@gmail.com>
To: Yuri Khan <yurivkhan@gmail.com>
Cc: "João Távora" <joaotavora@gmail.com>,
"Emacs developers" <emacs-devel@gnu.org>
Subject: Re: [PATCH] Accept plists when serializing and parsing JSON
Date: Sat, 2 Jun 2018 09:45:53 +0200 [thread overview]
Message-ID: <CAArVCkT6+RHaVVR=5uef_QVwdCWNwz22OKW7+4i5N1=qf7NFdg@mail.gmail.com> (raw)
In-Reply-To: <CAP_d_8W5U-nUgbT_O3gC=S4KVbH5DciAsiiak+SN7J0xZPs_0Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]
Yuri Khan <yurivkhan@gmail.com> schrieb am Mi., 30. Mai 2018 um 08:37 Uhr:
> On Wed, May 30, 2018 at 5:31 AM João Távora <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 believe 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 ‘foo’ and ‘bar’, both of which
> want to use the JSON library.
> * ‘foo’ wants plists while ‘bar’ wants alists.
> * ‘foo’ has a hook. The user adds to that hook a function that invokes
> ‘bar’.
> * 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
> …)) …), which is more cumbersome than just passing an argument to a
> function.
>
Yes, exactly. Any dynamic variable is effectively a hidden parameter.
That's much worse than an explicit parameter because you have to remember
that it's a parameter and explicitly bind it on every call.
Consider the Java equivalent:
class Json {
public static Object deserialize(String json) { ... } // uses
useHashtables
public static bool useHashtables = false;
}
Very few people would consider such an interface good style: there's a
subtle interaction between deserialize and useHashtables, and all callers
need to be aware of the interaction. But interfaces should be easy to use
correctly and hard to use incorrectly, and this interface is easy to use
incorrectly and hard to use correctly. BTW, This has nothing to do with
Java or ELisp, but is generally true for all (imperative) programming
languages: avoid mutable global state, avoid "action at a distance"
(seemingly unrelated parts of the code influencing each other). For ELisp,
this means: avoid introducing dynamic variables if possible.
[-- Attachment #2: Type: text/html, Size: 2976 bytes --]
next prev parent reply other threads:[~2018-06-02 7:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 14:59 [PATCH] Accept plists when serializing and parsing JSON João Távora
2018-05-29 21:20 ` Philipp Stephani
2018-05-29 22:03 ` João Távora
2018-05-30 6:37 ` Yuri Khan
2018-05-30 8:58 ` João Távora
2018-06-02 8:04 ` Philipp Stephani
2018-06-03 0:34 ` João Távora
2018-06-03 4:05 ` Stefan Monnier
2018-06-03 13:43 ` João Távora
2018-06-02 7:45 ` Philipp Stephani [this message]
2018-06-02 7:39 ` Philipp Stephani
2018-06-01 9:39 ` Eli Zaretskii
2018-06-01 23:29 ` João Távora
2018-06-02 6:55 ` Eli Zaretskii
2018-06-02 8:24 ` Philipp Stephani
2018-06-02 9:00 ` Eli Zaretskii
2018-06-02 16:46 ` Philipp Stephani
2018-06-02 19:18 ` Eli Zaretskii
2018-06-08 14:45 ` Eli Zaretskii
2018-06-02 8:30 ` Philipp Stephani
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='CAArVCkT6+RHaVVR=5uef_QVwdCWNwz22OKW7+4i5N1=qf7NFdg@mail.gmail.com' \
--to=p.stephani2@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@gmail.com \
--cc=yurivkhan@gmail.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.