Re: Last use of defadvice in Emacs

[Stefan Monnier]

> It would be nice if these issues (perhaps in less academic shape and
> in more practical terms) could be added to the ELisp manual,

Not sure what "more practical terms" would look like.

> because AFAICT we currently lack any rationale for people not to
> use defadvice.

BTW, in https://emacs.stackexchange.com/questions/3079/#3102
I mention a few other reasons, such as:

    • Design simplicity: defadvice has various notions that are
    generally difficult to understand precisely and/or rarely used.
    E.g. the difference between "enabling" and "activating" advices.
    Or the meaning of "pre" and/or "compiled".  There are also quirks in
    the handling of `ad-do-it`, such as the fact that it looks like
    a variable-reference rather than a call, or the fact that you need
    to (setq ad-return-value ...) explicitly rather than simply
    returning the value.

    • Defadvice suffers from various problems w.r.t macroexpansion and
    compilation: the body of an advice is not exposed as "code" (which
    the compiler and macroexpander see) but as "data" which is later on
    combined to make up an expression.  So macroexpansion happens late
    (which can causes surprises if you use things like
    `(eval-when-compile (require 'foo))`) and lexical-scoping is hard to
    preserve correctly.

E.g. regarding the first point, `ad-activate` or `ad-deactivate` are
arguably misdesigns since they have a global effect (they affect all
pieces of advice applied to a given function) and most uses of them are
latent bugs.

This said, I don't know how important it is to document those
advantages: AFAICT all coders familiar with the existence of both prefer
using `advice-add` already.  For new users who know neither, the doc
already nudges them towards `advice-add`.  Remains those who just
copy&paste existing code over which the doc has no influence, and more
importantly the vast number of existing code using `defadvice` for which
rewriting can't bring too many immediate benefit since the code
already works and we'd be lying if we tried to claim the rewritten code
is faster or objectively better.

To me the main benefit is that `advice-add` is simpler both in
implementation and in API (no need to learn about `add-(de)activate`,
`ad-(g|s)et-arg(s)`, `ad-do-it`, `ad-(en|dis)able-advice`, the
differences between "adding", "enabling", and "activating", the
occasional need to figure how and when to compile the code, ...).

Compare the size and complexity of Emacs's `advice.el` (which implements
the `defadvice` API on top of the `nadvice.el` one) to that of GNU
ELPA's `nadvice.el` (which implements the `advice-add` API on top of
`advice.el`): it's about 35× larger, yet both APIs cover adequately the
actual needs of packages.


        Stefan