[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Un-deprecating oset

From: Basil L. Contovounesios
Subject: Re: Un-deprecating oset
Date: Wed, 03 Jun 2020 15:03:35 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Jonas Bernoulli <jonas@bernoul.li>,  johnw@gnu.org,  emacs-devel@gnu.org
>> Date: Mon, 25 May 2020 12:06:54 -0400
>> > I tend to think it should be un-deprecated.
>> Interesting.  I thought the whole CL -> CL-lib change was because we
>> didn't want to have in Emacs core libraries that stomp on the namespace
>> like that (funnily enough most of EIEIO's global names come straight
>> from Common-Lisp, oref/oset being the main exception ;-)
>> So does that also mean that EIEIO's names are now accepted into the
>> core namespace?  It seems rather odd that `defclass` is allowed into the
>> core namespace while `defstruct` had to be relegated to `cl-defstruct`.
> I didn't mean we should stop cleaning up the global namespace, just
> that this case could be one of the few exclusions.

How's the attached patch for un-deprecating oset and oset-default?

Political rationale:
0. Most voiced opinions have been in favour of keeping oset.
1. Though most are in favour of cleaning EIEIO's namespace,
   deprecating only oset causes hassle without sufficient gain.

Technical rationale:
2. oset is widely used.
3. oref-default is not yet setf-able, so we'd have to recommend using
   eieio-oset-default in place of oset-default, which has been described
   as probably undesirable.


Should the changes to the manuals go to emacs-27 instead of master?



Attachment: 0001-Fix-some-EIEIO-obsoletions.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]