Re: Proposal: Forwards-Compatibility Library for Emacs

[Lars Ingebrigtsen]

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