[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.
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
- Re: Un-deprecating oset,
Basil L. Contovounesios <=