Re: Adding 'compat' from ELPA as an optional dependency to ERC

Philip Kaludercic <[email protected]>
Newsgroups gmane.emacs.erc.general,gmane.emacs.devel
Message-ID <[email protected]>
"J.P." <[email protected]> writes:

> Hi Philip (and Stefan),
>
> Philip Kaludercic <[email protected]> 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. 

There is always the possibility of changing compat to advise certain
functions instead of providing prefixed alternatives.  But that should
probably be decided in a case-by-case basis.

Depending on the interest of the Emacs maintainers in `compat' as a
project, it might also be possible to add compat-* definitions to the
core, thought I am not certain sure how fond I am of this idea.

>                              
>                              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))

If a function like this were to be definied upstream

        (defun get-compatibility-func (name)
          "Return the function NAME of a compatibility alias."
          (let* ((compat (intern-soft (format "compat-%s" name))))
            (or (symbol-function (if (fboundp name) name compat))
                (error "No definition for %S could be found" name))))

then all that ERC would have to do is

        (defalias 'erc-json-parse-string
          (get-compatibility-func 'json-parse-string))

> But in ERC's case, there'd be no avoiding this kind of indirection.
> (Please correct me if that's a flawed understanding.)

While prefixing is used, no, because we cannot assume that compat is
installed.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.