From: Stefan Monnier via CC-Mode-help <cc-mode-help@lists.sourceforge.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: bug-cc-mode@gnu.org, acm@muc.de, emacs-devel@gnu.org, raman@google.com
Subject: Re: Last use of defadvice in Emacs
Date: Thu, 07 Apr 2022 17:59:41 -0400 [thread overview]
Message-ID: <jwvtub4ps3j.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <834k35ctd4.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 07 Apr 2022 09:14:47 +0300")
> 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
next prev parent reply other threads:[~2022-04-07 21:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 19:49 Last use of defadvice in Emacs Stefan Monnier
2022-04-04 20:08 ` T.V Raman
2022-04-04 20:38 ` Stefan Monnier via CC-Mode-help
2022-04-04 20:48 ` T.V Raman
2022-04-05 4:28 ` Richard Stallman
2022-04-06 18:52 ` Alan Mackenzie
2022-04-06 21:08 ` Stefan Monnier via CC-Mode-help
2022-04-07 1:51 ` T.V Raman
2022-04-07 2:49 ` Stefan Monnier via CC-Mode-help
2022-04-07 6:14 ` Eli Zaretskii
2022-04-07 21:59 ` Stefan Monnier via CC-Mode-help [this message]
2022-04-08 1:49 ` T.V Raman
2022-04-08 2:34 ` Stefan Monnier via CC-Mode-help
2022-04-08 14:21 ` T.V Raman
2022-04-08 6:00 ` Eli Zaretskii
2022-04-07 18:18 ` Alan Mackenzie
2022-04-07 18:37 ` Stefan Monnier
2022-04-08 17:10 ` Alan Mackenzie
2022-04-08 17:39 ` Stefan Monnier via CC-Mode-help
2022-04-08 18:06 ` Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvtub4ps3j.fsf-monnier+emacs@gnu.org \
--to=cc-mode-help@lists.sourceforge.net \
--cc=acm@muc.de \
--cc=bug-cc-mode@gnu.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=raman@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.