From: Lars Ingebrigtsen <larsi@gnus.org>
To: "João Távora" <joaotavora@gmail.com>
Cc: Philip Kaludercic <philipk@posteo.net>,
Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel <emacs-devel@gnu.org>
Subject: Re: Proposal: Forwards-Compatibility Library for Emacs
Date: Tue, 21 Sep 2021 19:22:06 +0200 [thread overview]
Message-ID: <87bl4lzvwh.fsf@gnus.org> (raw)
In-Reply-To: <CALDnm50CTaebnAT9Src8xU8d+WU9C_z7BgCwpXJ8cMa-xhEp4Q@mail.gmail.com> ("João Távora"'s message of "Tue, 21 Sep 2021 16:40:55 +0100")
João Távora <joaotavora@gmail.com> writes:
> It was Philip who described as "intrusive", "by its very nature",
> since it relies on advice and such. This can be seen as "dirty" in itself.
> But say that the contract/promise that a given function in Emacs 28 makes
> is different from the promise that the same function in Emacs 24.2 makes.
> The new ELPA code doesn't have a problem, but you have potential problem
> to all the other 24.2 code that expects the "old promise". Right?
Yes, some compatibility shims may be problematic -- especially if they
aren't bug-compatible.
But I think the general idea is good, as long as we don't go overboard.
That is, if a new library function is introduced in Emacs core, then
having it in compat.el is always fine. Extending function that gain
more parameters, on the other hand, may or may not be problematic, and
should be considered on a case by case basis.
The "NO NON-NAMESPACED COMPAT FUNCTION" thing that became a part of
Emacs culture happened because in the 90s there were several problems in
this area. One thing that happened was that several packages defined
the same names for functions that did totally different things. Another
thing that happened was that "compat" libraries defined their own
versions of functions even if Emacs core defined the functions in
question.
Neither issue is a problem with the proposed compat library. It's a
single, "officially blessed" library, and it doesn't redefine anything
that's already defined.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
next prev parent reply other threads:[~2021-09-21 17:22 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 23:35 Proposal: Forwards-Compatibility Library for Emacs Philip Kaludercic
2021-09-21 0:30 ` Adam Porter
2021-09-21 4:10 ` Lars Ingebrigtsen
2021-09-21 8:28 ` Philip Kaludercic
2021-09-21 12:31 ` Stefan Monnier
2021-09-21 12:40 ` Eli Zaretskii
2021-09-21 12:50 ` Stefan Kangas
2021-09-21 13:38 ` Arthur Miller
2021-09-21 13:49 ` João Távora
2021-09-21 13:00 ` Philip Kaludercic
2021-09-21 13:12 ` Eli Zaretskii
2021-09-21 13:28 ` Philip Kaludercic
2021-09-21 13:24 ` João Távora
2021-09-21 13:29 ` Philip Kaludercic
2021-09-21 13:50 ` João Távora
2021-09-21 14:59 ` Lars Ingebrigtsen
2021-09-21 12:58 ` Philip Kaludercic
2021-09-21 13:37 ` Arthur Miller
2021-09-21 13:54 ` Philip Kaludercic
2021-09-21 14:18 ` Arthur Miller
2021-09-21 15:02 ` Lars Ingebrigtsen
2021-09-21 15:40 ` João Távora
2021-09-21 16:10 ` Philip Kaludercic
2021-09-21 16:22 ` João Távora
2021-09-21 17:22 ` Lars Ingebrigtsen [this message]
2021-09-21 17:29 ` João Távora
2021-09-21 19:24 ` Stefan Monnier
2021-09-21 21:06 ` Philip Kaludercic
2021-09-21 21:50 ` Stefan Monnier
2021-09-22 6:48 ` Philip Kaludercic
2021-09-22 17:53 ` Stefan Monnier
2021-09-22 18:54 ` Philip Kaludercic
2021-09-22 19:15 ` Stefan Monnier
2021-09-21 21:57 ` Lars Ingebrigtsen
2021-09-21 22:08 ` João Távora
2021-09-21 22:16 ` Lars Ingebrigtsen
2021-09-21 22:24 ` João Távora
2021-09-21 22:25 ` Lars Ingebrigtsen
2021-09-21 22:34 ` João Távora
2021-09-22 6:53 ` Philip Kaludercic
2021-09-22 7:12 ` João Távora
2021-09-22 7:14 ` Arthur Miller
2021-09-21 13:05 ` Philip Kaludercic
2021-09-21 13:27 ` Arthur Miller
2021-09-21 13:45 ` Philip Kaludercic
2021-09-21 14:05 ` Arthur Miller
2021-09-21 22:17 ` Richard Stallman
2021-09-21 22:24 ` Lars Ingebrigtsen
2021-09-22 9:54 ` Philip Kaludercic
2021-10-04 23:00 ` [ELPA] Add compat.el Philip Kaludercic
2021-10-07 7:03 ` Old (static) builds of Emacs Philip Kaludercic
2021-10-07 7:48 ` Michael Albinus
2021-10-07 7:56 ` Philip Kaludercic
2021-10-07 12:49 ` Stefan Monnier
2021-10-07 20:29 ` Philip Kaludercic
2021-10-07 21:21 ` Stefan Monnier
2021-11-30 21:21 ` Philip Kaludercic
2021-12-01 13:15 ` Stefan Monnier
2021-10-07 20:49 ` [ELPA] Add compat.el Philip Kaludercic
2021-10-08 5:56 ` Eli Zaretskii
2021-10-08 9:59 ` Philip Kaludercic
2021-10-08 11:10 ` Eli Zaretskii
2021-10-08 11:35 ` Philip Kaludercic
2021-10-08 7:45 ` Mattias Engdegård
2021-10-08 10:00 ` Philip Kaludercic
2021-10-15 19:08 ` Philip Kaludercic
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bl4lzvwh.fsf@gnus.org \
--to=larsi@gnus.org \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=philipk@posteo.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).