[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adding 'compat' from ELPA as an optional dependency to ERC
From: |
J.P. |
Subject: |
Re: Adding 'compat' from ELPA as an optional dependency to ERC |
Date: |
Tue, 19 Jul 2022 15:34:44 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Hi Philip (and Stefan),
Philip Kaludercic <philipk@posteo.net> writes:
> By explicitly loading
> compat-28, one would additionally load "prefixed" definitions for
> functions that add new features to existing functions.
>
> E.g. consider how assoc acquired a new optional argument "TESTFN" in
> version 26. One would either have to advise the existing function,
> which was regarded to be too invasive and dangerous, or to define a
> separate function underneath the `compat-' prefix -- `compat-assoc'.
>
> This function is not made visible by loading `compat', and explicitly
> ought not to be in this case, as someone using the in-tree version of
> ERC would not have no such function defined. In this sense the support
> compat can provide for core packages is limited, but as it seems for
> ERC's requirements sufficient.
I suppose we could always add prefixed definitions down the road if
really needed, perhaps to spare us from having to copy some complicated
backport definition in full. Although, I believe doing so would also
define compat- prefixed variants in all versions of Emacs, the idea
being to save third-party packages from having to do stuff like
(defmacro erc-compat--json-parse-string (string &rest args)
`(,(if (fboundp 'compat-json-parse-string)
'compat-json-parse-string
'json-parse-string)
,string
,@args))
But in ERC's case, there'd be no avoiding this kind of indirection.
(Please correct me if that's a flawed understanding.)
Thanks,
J.P.