GNU bug report logs - #40693
28.0.50; json-encode-alist changes alist

Previous Next

Full log

Message #106 received at 40693 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: darthandrus <at> gmail.com, 40693 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#40693: 28.0.50; json-encode-alist changes alist
Date: Thu, 21 May 2020 23:16:30 +0100

"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
> The declarations are needed because the byte-compiler does not know that
> loading json.el will e.g. define a dynamically bound variable
> json-object-type and a nullary function symbol json-read.  It therefore
> not only complains but also generates invalid byte-code.

Basil, I understand the need for the declarations, but I was suggesting
something different.  This, at the top, near all the other requires.

   (eval-and-compile
     (unless (fboundp 'json-parse-buffer)
       (require 'json)))

and then do the defalias without the declarations below.

   (defalias blabla
      (if (fboundp 'json-parse-buffer)
          (lambda () json-c-things...)
          (lambda () json-el-things...)))

Am I missing something or doesn't this work like you want?  We're
checking json.c function thrice instead of twice, but doesn't seem very
bad, only a 50% increase :-)

> But I find this more heavy handed and intrusive, since it
> unconditionally loads json.el during byte-compilation, even when
> json-parse-buffer is available.

I think the snippet above doesn't have this problem.

Anyway, this is a minor nitpick, push whatever you think is better.

João

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.