[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dealing with obsoletion warnings in non-core code
From: |
Eli Zaretskii |
Subject: |
Re: Dealing with obsoletion warnings in non-core code |
Date: |
Mon, 28 Sep 2020 22:00:22 +0300 |
> Date: Mon, 28 Sep 2020 20:34:57 +0200
> From: Vasilij Schneidermann <mail@vasilij.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>
> > (if (> emacs-major-version NN)
> > (defun recommended-function (...)
> > ...))
>
> You don't want a third-party package defining a potentially
> non-conformant version of future built-in functionality
We've been using such shims in packages that supported both Emacs and
XEmacs, for eons. I don't see how it's suddenly so wrong.
> (for example if they take the definition from a specific Emacs
> version and it changes in another one)
That's a separate problem, and will happen even if you only support
versions where the function is available. It's why we try very hard
not to make backward-incompatible changes in public APIs.
> Besides, isn't the logic the wrong way around? The recommended function
> is something available in a newer Emacs version, so you'd test for an
> older one and if the check is positive, define the shim.
You assume that the older one is removed? That usually doesn't
happen.
> Assuming you can even, some functionality cannot be backported that
> easily.
If the functionality cannot be had at all, there's no problem: just
provide a no-op function by that name.
Anyway, you asked how to avoid warning messages, and I suggested a way
which should do that. If that's not what you want, fine; I tried to
help you.
Re: Dealing with obsoletion warnings in non-core code, Gregory Heytings, 2020/09/29
Re: Dealing with obsoletion warnings in non-core code, T.V Raman, 2020/09/29