bug#60311: json-available-p: make dynamically correct for Windows

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

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.