Re: Un-deprecating oset

[Basil L. Contovounesios]

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.

WDYT?

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

Thanks,

-- 
Basil

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