please consider keeping defadvice around

please consider keeping defadvice around

[Madhu]

* commit 27ed565ec6163c499191b62a4cee10d99019aa38
| Author:     Stefan Monnier <monnier@iro.umontreal.ca>
| AuthorDate: Thu Aug 3 23:41:11 2023 -0400
| Commit:     Stefan Monnier <monnier@iro.umontreal.ca>
| CommitDate: Thu Aug 3 23:41:11 2023 -0400
|
|    * lisp/emacs-lisp/advice.el (defadvice): Mark as obsolete

defadvice is a carefully designed and well documented piece of
software.  It provides a very useful abstraction on how to define
advice and provides easy hooks to disable specific advice, unadvise
and redefine advices.  At the least this is essential porcelein which
has to be reimplemente on top of the add-function add-advice plumbing.

I can see no good reason to deprecate and remove defadvice which is
valuble for both its design and beautiful documentation.  Removal
would only force the user to use the new sparesly-documented
interfaces to produce write-only opaque unnamed-closure-based
undebuggable code.

Re: please consider keeping defadvice around

[Adam Porter]

> * commit 27ed565ec6163c499191b62a4cee10d99019aa38
> | Author:     Stefan Monnier <monnier@iro.umontreal.ca>
> | AuthorDate: Thu Aug 3 23:41:11 2023 -0400
> | Commit:     Stefan Monnier <monnier@iro.umontreal.ca>
> | CommitDate: Thu Aug 3 23:41:11 2023 -0400
> |
> |    * lisp/emacs-lisp/advice.el (defadvice): Mark as obsolete
> 
> defadvice is a carefully designed and well documented piece of
> software.  It provides a very useful abstraction on how to define
> advice and provides easy hooks to disable specific advice, unadvise
> and redefine advices.  At the least this is essential porcelein which
> has to be reimplemente on top of the add-function add-advice plumbing.
> 
> I can see no good reason to deprecate and remove defadvice which is
> valuble for both its design and beautiful documentation.  Removal
> would only force the user to use the new sparesly-documented
> interfaces to produce write-only opaque unnamed-closure-based
> undebuggable code.

What about DEFINE-ADVICE?  It seems to imitate the old DEFADVICE but 
using the new nadvice library.

As well, the shortcomings of the old advice library, and improvements of 
the new nadvice library, are documented in the Elisp manual.  It seems 
like a worthy replacement.

Re: please consider keeping defadvice around

[Madhu]

*  Adam Porter <adam@alphapapa.net> <3750971b-2947-65a4-b25f-d3a95a9c9c30@alphapapa.net>
Wrote on Sun, 10 Sep 2023 03:46:54 -0500

>> * commit 27ed565ec6163c499191b62a4cee10d99019aa38
>> | Author:     Stefan Monnier <monnier@iro.umontreal.ca>
>> | AuthorDate: Thu Aug 3 23:41:11 2023 -0400
>> | Commit:     Stefan Monnier <monnier@iro.umontreal.ca>
>> | CommitDate: Thu Aug 3 23:41:11 2023 -0400
>> |
>> |    * lisp/emacs-lisp/advice.el (defadvice): Mark as obsolete
>> defadvice is a carefully designed and well documented piece of
>> software.  It provides a very useful abstraction on how to define
>> advice and provides easy hooks to disable specific advice, unadvise
>> and redefine advices.  At the least this is essential porcelein which
>> has to be reimplemente on top of the add-function add-advice plumbing.
>> I can see no good reason to deprecate and remove defadvice which is
>> valuble for both its design and beautiful documentation.  Removal
>> would only force the user to use the new sparesly-documented
>> interfaces to produce write-only opaque unnamed-closure-based
>> undebuggable code.
>
> What about DEFINE-ADVICE?  It seems to imitate the old DEFADVICE but
> using the new nadvice library.

DEFADVICE also uses the new framework.

All my concerns above stand.  The claim that it is "simpler" is
specious and does injustice to the earlier design and is
propaganada. The documentation of the new defadvice again defers to
the implementation details, does not provide the abstratcions that
were provided the difference in the quality of the documentation is
apparent.

> As well, the shortcomings of the old advice library, and
> improvements of the new nadvice library, are documented in the Elisp
> manual.  It seems like a worthy replacement.

The nadvice is freely available to use.  I see the obsoleting the old
mechanism is a move to destroy value and invalidate a valid design,
presumable based on personal prejudice.

Re: please consider keeping defadvice around

[Eli Zaretskii]

> Date: Mon, 11 Sep 2023 07:20:32 +0530 (IST)
> Cc: emacs-devel@gnu.org
> From: Madhu <enometh@meer.net>
> 
> I see the obsoleting the old mechanism is a move to destroy value
> and invalidate a valid design, presumable based on personal
> prejudice.

IMNSHO, that is a serious misrepresentation of the real reasons, which
were abundantly explained here.

Re: please consider keeping defadvice around

[Madhu]

*  Eli Zaretskii <eliz@gnu.org> <83y1hdqw8t.fsf@gnu.org>
Wrote on Mon, 11 Sep 2023 05:28:18 +0300
>> Date: Mon, 11 Sep 2023 07:20:32 +0530 (IST)
>> From: Madhu <enometh@meer.net>
>>
>> I see the obsoleting the old mechanism is a move to destroy value
>> and invalidate a valid design, presumable based on personal
>> prejudice.
>
> IMNSHO, that is a serious misrepresentation of the real reasons, which
> were abundantly explained here.

The concerns in my first post on this thread remain valid.  The
motivations alluded above are not enough to warrant the deprecation
and removal of the original design, and therefore compel the
interpretation you object to.

Re: please consider keeping defadvice around

[Emanuel Berg]

Madhu wrote:

>>> I see the obsoleting the old mechanism is a move to
>>> destroy value and invalidate a valid design, presumable
>>> based on personal prejudice.
>>
>> IMNSHO, that is a serious misrepresentation of the real
>> reasons, which were abundantly explained here.
>
> The concerns in my first post on this thread remain valid.
> The motivations alluded above are not enough to warrant the
> deprecation and removal of the original design, and
> therefore compel the interpretation you object to.

Have you assessed the proposed alternative?

Maybe you find that you like it, in which case replacing the
"original design" will improve the state of whatever it is
that uses it?

-- 
underground experts united
https://dataswamp.org/~incal

Re: please consider keeping defadvice around

[Eli Zaretskii]

> Date: Mon, 11 Sep 2023 08:09:49 +0530 (IST)
> Cc: adam@alphapapa.net, emacs-devel@gnu.org
> From: Madhu <enometh@meer.net>
> 
> *  Eli Zaretskii <eliz@gnu.org> <83y1hdqw8t.fsf@gnu.org>
> Wrote on Mon, 11 Sep 2023 05:28:18 +0300
> >> Date: Mon, 11 Sep 2023 07:20:32 +0530 (IST)
> >> From: Madhu <enometh@meer.net>
> >>
> >> I see the obsoleting the old mechanism is a move to destroy value
> >> and invalidate a valid design, presumable based on personal
> >> prejudice.
> >
> > IMNSHO, that is a serious misrepresentation of the real reasons, which
> > were abundantly explained here.
> 
> The concerns in my first post on this thread remain valid.  The
> motivations alluded above are not enough to warrant the deprecation
> and removal of the original design

We disagree with this, and think that the motivation _is_ enough.  We
provide alternatives to defadvice that we think are better and not
less powerful.

Of course, Emacs is Free Software, so please feel free to modify your
copy such that this particular deprecation is removed.

Re: please consider keeping defadvice around

[Po Lu]

Folks, defadvice is merely obsolete -- no proposal to remove it has
hitherto surfaced.

I favor retaining defadvice indefinitely, of course, but the time for
making that decision is still many years in the future.  Let's postpone
it until then: threads like this one uniformly regress into protracted
series of largely frivolous diatribes, whose counter-productivity is an
established uncontested fact.  We've witnessed two this month.  Do we
really need another?