[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#60311: json-available-p: make dynamically correct for Windows
From: |
Mattias Engdegård |
Subject: |
bug#60311: json-available-p: make dynamically correct for Windows |
Date: |
Mon, 26 Dec 2022 13:11:21 +0100 |
25 dec. 2022 kl. 16.40 skrev Eli Zaretskii <eliz@gnu.org>:
> Yes, you are right. But please come up with a smaller changeset which
> only changes what strictly needs to be changed. Or if you want, I can
> do this myself.
Since you have very specific ideas about how to go about it it's better that
you make the change yourself. After all, attempts to remote-control someone
else this way rarely make either party very happy.
As long as it gets done I'm not very particular about it myself.
>> + (and (eval-when-compile (fboundp 'json-serialize))
>> + ;; If `json--available-p' is present, we need to call it at run-time.
>> + (or (not (eval-when-compile (fboundp 'json--available-p)))
>> + (json--available-p))))
>
> Btw, I don't understand this use of eval-when-compile here. Can you
> explain why should we care at compile time whether these functions are
> fboundp?
Because we can: we already know the answers when subr.el is compiled, giving us
constant nil or t values that will simplify the function to a constant or a
call to json--available-p.
> why not just
>
> (and (fboundp 'json--available-p)
> (json--available-p))
Calling `fboundp` at run time is wasteful, and that patch used the presence of
json--available-p to indicate whether it needs to be called at run time (on
Windows only, but it's good to keep that platform-dependency in one place).
It doesn't matter much if json-available-p is implemented in Lisp or C; even
performance-wise it's a wash.