Un-deprecating oset

Un-deprecating oset

[Jonas Bernoulli]

Stefan send be a patch, which among other things, addressed the very
recent deprecation of `oset' in favor of (setf (oref ...)...).

I think this deprecation should be discussed here.  This is what we
wrote to each other so far (posting with his permission):

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I hope this change will be reverted.  I *like* `setf', but while I
>> don't miss--say--`alist-set', existing setters should not be removed,
>> IMO.  What do we gain by deprecating `oset', except additional work?
>
> EIEIO's abuse of namespace is terrible.  Removing `oset` is just
> another step towards a bit more sanity [...]  If you want a setter
> function, there's still `eieio-oset` which I have no intention to
> remove or deprecate.

And now...

I used to assume that `oref' and `oset' were traditional CLOS functions
but now that I have actually looked around a bit I realize I likely was
wrong about that.

I found some documents about CLOS that mention `slot-value' and
`with-slots' but never `oref' and `oset'; so now I assume that the
latter two are EIEIO additions.  That of course makes it a bit harder
to argue in favor of `oset' (or `oref').

I can think of the following approaches to set a slot:

  1. (oset object slot value)
  2. (eieio-oset object 'slot value)
  3. (setf (oref object slot) value)
  4. (setf (eieio-oref object 'slot) value)
  5. (setf (slot-value object 'slot) value)
  6. (with-slots (slot) object (setq slot value))

The deprecation warning of `oset' suggests that we stop using [1] and
use [3] instead.  As I mentioned before I don't understand what that
change accomplishes.

Above you state the goal of "namespace sanity" and suggest the use of
[2].  That seems to make a lot more sense and one might argue that the
deprecation warning should be changed to make that suggestion.

I still prefer [1] but am willing to go with the flow.  However at this
time I fail to see where that is taking us.

You mention that you do NOT intend to remove `eieio-oset'.  And that
can only mean that `eieio-oref' is safe too -- right?  But what about
`slot-value'?  It is a traditional CLOS function, but does that count
for anything?  And is `slot-' maybe even considered an acceptable
prefix?

I still don't really think [3] makes sense as the preferred approach,
and yet I somehow have come to gravitate toward that as my fallback,
now that may favorite approach has been deprecated.

I think both `eieio-oref' and `eieio-oset' are awful, even now that it
has turned out that `oref' and `oset' (probably) are EIEIO inventions.
It feels like renaming `setq' to `variable-setq'!  I feel that
"get/set the value"-functions should all have rather short names and
that this does not only apply to the most important such functions,
like `setf', but also to e.g. `get'/`put' and, yes, `oref'/`oset'.

Object-oriented programming is not a core language feature, but does
that mean it has to be treated as a second class citizen?  I feel this
deprecation is much more significant than e.g. deprecating `loop' in
favor of `cl-loop'.

So after rewriting this mail several times and learning more about my
own conflicting and still evolving thoughts on the matter, I currently
think the following is what I cannot get over with.

The deprecation of `oset' appears to be motivated by two IMO unrelated
goals:

  A. Take another step towards the elimination of prefix-less symbols.

  B. Avoid unnecessary setters.  Use `setf' instead.

And I can--more or less--subscribe to both of these goals, but here they
come together in a problematic way, especially because these two goals,
and how they relate, are not clearly stated.

  I.   Iff we agree that "needless setters" should be deprecated, then
       I might come around to support that, but this would have to be
       about *all* the setters.  Why deprecate `oset' but not `set'?

  II.  I might come to agree that `oref' and `oset' should get a
       prefix.  I would probably argue that it should not be `eieio-'
       but maybe `cl-' or `slot-'.  Or `object-get' and `object-set',
       I suppose.

  III. But I simply do not understand how it makes sense to deprecate
       `oset' without *at the same time* deprecating `oref' as well.

       - Without assurances otherwise, I cannot shake off the feeling
         that as soon as I have gotten used to `oset' not being around
         anymore, then `oref' will be removed as well. (I would rather
	 get it over with in one go.)

I think it boils down to this for me:

       - If `oset' is so bad, then `oref' must be just as bad, right?
       
         If we commit to keeping `oref' around, then why not do the
         same for `oset'?  If we commit to never remove one of these
         two, then why even bother removing the other?  As long as we
         keep `oref', the ghost of `oset' will hang on, and now you
         have not only a mess but a *haunted* mess.

TL;DR

Deprecating (oref object slot value)
in favor of (setf (oref object slot) value)
does *nothing* to increase "namespace sanity", the declared goal.
It does however take away the programmers choice whether to use
`setf' or not, but only when it comes to OOP, which seems unfair.

--
Jonas

PS: I am mostly AFK today.  Posting this now anyway because follow
    up actions are already being carried out.

Re: Un-deprecating oset

[Philippe Vaucher]

> Deprecating (oref object slot value)
> in favor of (setf (oref object slot) value)
> does *nothing* to increase "namespace sanity", the declared goal.
> It does however take away the programmers choice whether to use
> `setf' or not, but only when it comes to OOP, which seems unfair.

If I followed correctly the first line should read "(oset object slot
value)" (not oref), but I think most people will be able to
autocorrect.

Re: Un-deprecating oset

[Basil L. Contovounesios]

Jonas Bernoulli <jonas@bernoul.li> writes:

> TL;DR
>
> Deprecating (oref object slot value)
> in favor of (setf (oref object slot) value)
> does *nothing* to increase "namespace sanity", the declared goal.
> It does however take away the programmers choice whether to use
> `setf' or not, but only when it comes to OOP, which seems unfair.
>
> --
> Jonas
>
> PS: I am mostly AFK today.  Posting this now anyway because follow
>     up actions are already being carried out.

Sorry, I haven't been following the namespace discussions and my only
intention in [1] was to get Emacs building cleanly again.  I'll hold off
on pushing that for now.

[1]: https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00630.html

Two notes I can offer after putting that patch together:

1. While oref has been setf-able for a while, oref-default is not.  So
   Elisp libraries won't be able to write (setf (oref-default ...) ...)
   until Emacs 28 at the earliest.

2. As the patch indicates, oset is used *a lot*.

-- 
Basil

Re: Un-deprecating oset

[Stefan Monnier]

> I used to assume that `oref' and `oset' were traditional CLOS functions
> but now that I have actually looked around a bit I realize I likely was
> wrong about that.

Indeed, CLOS uses `slot-value` instead.

> I found some documents about CLOS that mention `slot-value' and
> `with-slots'

In my mind (and I expect it's also the case in all implementations),
`with-slots` is built on top of `slot-value`.

> but never `oref' and `oset'; so now I assume that the latter two are
> EIEIO additions.

Indeed.

> I can think of the following approaches to set a slot:
>   1. (oset object slot value)
>   2. (eieio-oset object 'slot value)
>   3. (setf (oref object slot) value)
>   4. (setf (eieio-oref object 'slot) value)
>   5. (setf (slot-value object 'slot) value)
>   6. (with-slots (slot) object (setq slot value))

Right.  And only 5 and 6 work in CLOS.

> Above you state the goal of "namespace sanity" and suggest the use of
> [2].  That seems to make a lot more sense and one might argue that the
> deprecation warning should be changed to make that suggestion.

I don't have a strong preference either way: I'm more interested in
deprecating `oset` than in the choice of the alternative we
should recommend.

But FWIW, I chose (3) as the recommendation on the following basis:

- I expect most people to consider `eieio-oset` as an ugly name.

- `setf` on `slot-value` is significantly more verbose and hence will
  encounter more resistance.

- I like `setf` and using it sometimes makes further rewrite more
  obvious when the textually identical (oref X Y) appears.  E.g.

      (oset X Y (cons Z (oref X Y)))
  vs
      (setf (oref X Y) (cons Z (oref X Y)))

  where I don't know about you, but my brain tends to suggest

      (push Z (oref X Y))

  when it sees the second but not the first.

But again I'm not at all wedded to this suggestion (and we can also
recommend *several* options if we want).

> You mention that you do NOT intend to remove `eieio-oset'.  And that
> can only mean that `eieio-oref' is safe too -- right?

Yes.  They're safe because they use the `eieio-` prefix which cleanly
belongs to (and is used by) the `eieio` package.

> But what about `slot-value'?

Good question.  There's something to be said for bringing it into the
`cl-` namespace (along with `defclass`) but it hasn't happened yet and
I haven't found the stamina to undertake this job.

[ To be honest, I dislike EIEIO: not only it stomps all over the
  namespace but I dislike objects whose field access requires
  a hash-table lookup, which is why I only use `cl-defstruct`.  ]

> "get/set the value"-functions should all have rather short names and
> that this does not only apply to the most important such functions,
> like `setf', but also to e.g. `get'/`put' and, yes, `oref'/`oset'.

Makes sense (tho I'm in the camp of those who prefer to strive for
immutable objects, so I do want a concise object-access but I'm quite
willing to use a significantly more verbose object-modification syntax).

> Object-oriented programming is not a core language feature, but does
> that mean it has to be treated as a second class citizen?

That is definitely not the intention.

> The deprecation of `oset' appears to be motivated by two IMO unrelated
> goals:
>
>   A. Take another step towards the elimination of prefix-less symbols.
>
>   B. Avoid unnecessary setters.  Use `setf' instead.

The goal was only (A): we can't avoid setters because they are visible
in the macroexpansion of `setf` and get stored in `.elc` files.
So while I did choose the `(setf (oref ..) ...)` recommendation based on
a preference for `setf` there is no intention to *avoid* setter
functions, because setter functions are indispensable (even if they
don't appear in the source code).

Common Lisp does try to avoid setter functions and *can* hide them, but
Elisp can't really hide them.

>   II.  I might come to agree that `oref' and `oset' should get a
>        prefix.  I would probably argue that it should not be `eieio-'
>        but maybe `cl-' or `slot-'.  Or `object-get' and `object-set',
>        I suppose.

I think the design of the namespacing of `oref` would have to be done
along with that of `slot-value`, `defclass`, etc...

>   III. But I simply do not understand how it makes sense to deprecate
>        `oset' without *at the same time* deprecating `oref' as well.

I could go along with that.  I expect this will encounter more
resistance, tho.

>        - Without assurances otherwise, I cannot shake off the feeling
>          that as soon as I have gotten used to `oset' not being around
>          anymore, then `oref' will be removed as well. (I would rather
> 	   get it over with in one go.)

"As soon as": I'd say it's unlikely.

> It does however take away the programmers choice whether to use
> `setf' or not, but only when it comes to OOP, which seems unfair.

I don't understand this "programmers choice" argument.
You can use either `eieio-oset` or (lambda (..) (setf (oref ..) ..)) if
you need a function, so the choice still exists just as much as before.


        Stefan

Re: Un-deprecating oset

[Jonas Bernoulli]

Well, it seems nobody else (who has noticed so far) shares my opinion
(enough to comment here).  I'll go replace my uses of `oset' now.

I still think it doesn't make sense to remove `oset' while keeping
`oref', which I said best in the only part of my earlier mail that
you did not quote:

>       - If `oset' is so bad, then `oref' must be just as bad, right?
>
>	 If we commit to keeping `oref' around, then why not do the
>	 same for `oset'?  If we commit to never remove one of these
>	 two, then why even bother removing the other?  As long as we
>	 keep `oref', the ghost of `oset' will hang on, and now you
>	 have not only a mess but a *haunted* mess.

But I won't keep arguing that opinion because I don't want to risk
that you actually end up removing `oref' as a result well.  ;D

  Jonas

Re: Un-deprecating oset

[Philippe Vaucher]

> Well, it seems nobody else (who has noticed so far) shares my opinion
> (enough to comment here).  I'll go replace my uses of `oset' now.

FWIW I do agree with you. Let's keep oset.

That said I'm not impacted by this deprecation so it's hard for me to
be really concerned about it.

Re: Un-deprecating oset

[Adam Porter]

Jonas Bernoulli <jonas@bernoul.li> writes:

> Well, it seems nobody else (who has noticed so far) shares my opinion
> (enough to comment here).  I'll go replace my uses of `oset' now.

Since you asked (sort of): If I had to vote, I'd vote in favor of
keeping oset rather than deprecating it.  I generally like using setf,
but (setf (oref ...))  feels unnecessarily verbose compared to (oset
...).  But if oset didn't already exist, I'm not sure I'd favor adding
it.

For myself, if Stefan wants to deprecate it, I can live with that.

Of course, you've written orders of magnitude more EIEIO-using code than
I have (I wouldn't be surprised if you've written more than anyone), so
your perspective is different from mine.  :)

Re: Un-deprecating oset

[Philipp Stephani]

Am Di., 12. Mai 2020 um 17:32 Uhr schrieb Jonas Bernoulli <jonas@bernoul.li>:
>
> Well, it seems nobody else (who has noticed so far) shares my opinion
> (enough to comment here).

I definitely agree that oset shouldn't be deprecated. Not that I like
it with a passion, but we should in general never deprecate anything
that isn't actually broken or causes trouble. This deprecation seems
to be mostly motivated by a desire for hypothetical cleanliness, which
isn't a good enough reason.

Re: Un-deprecating oset

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

On Wed, May 13, 2020 at 3:06 PM Philipp Stephani <p.stephani2@gmail.com>
wrote:

> This deprecation seems
> to be mostly motivated by a desire for hypothetical cleanliness, which
> isn't a good enough reason.

Also, it generates 1255 new warnings (plus an additional 20 from
oset-default). Cleaning that is going to be... entertaining.

[-- Attachment #2: Type: text/html, Size: 450 bytes --]

Re: Un-deprecating oset

[Basil L. Contovounesios]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Wed, May 13, 2020 at 3:06 PM Philipp Stephani <p.stephani2@gmail.com> wrote:
>
>> This deprecation seems
>> to be mostly motivated by a desire for hypothetical cleanliness, which
>> isn't a good enough reason.
>
> Also, it generates 1255 new warnings (plus an additional 20 from oset-default). Cleaning that is going to be...
> entertaining.

What can I say, I'm a fool for entertainment. ;)

https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00630.html

-- 
Basil

Re: Un-deprecating oset

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

On Thu, May 14, 2020 at 2:13 PM Basil L. Contovounesios <contovob@tcd.ie>
wrote:

> What can I say, I'm a fool for entertainment. ;)

I've been known to do that kind of thing in the past. ;-)

[-- Attachment #2: Type: text/html, Size: 292 bytes --]

Re: Un-deprecating oset

[Jonas Bernoulli]

Stefan, we have now have heard a few additional voices that are mildly
in favor of keeping `oset'.  What's next?

Philipp Stephani <p.stephani2@gmail.com> writes:
> I definitely agree that oset shouldn't be deprecated. Not that I like
> it with a passion, but we should in general never deprecate anything
> that isn't actually broken or causes trouble. This deprecation seems
> to be mostly motivated by a desire for hypothetical cleanliness, which
> isn't a good enough reason.

Seems like a good argument to me.  Much shorter than when I tried.

  Jonas

Re: Un-deprecating oset

[Jonas Bernoulli]

I wrote:
> Stefan, we [...] now have heard a few additional voices that are
> mildly in favor of keeping `oset'.  What's next?

and elsewhere Stefan replied:

> I don't plan to un-deprecate it (the discussion didn't bring up
> any novel point from my point of view, so my opinion is the same
> as before) unless Eli or John asks for it.

So I am now asking Eli and John to comment.

As I said before this argument by Philipp Stephani sums up pretty well
what is my position too:

>> I definitely agree that oset shouldn't be deprecated. Not that I like
>> it with a passion, but we should in general never deprecate anything
>> that isn't actually broken or causes trouble. This deprecation seems
>> to be mostly motivated by a desire for hypothetical cleanliness, which
>> isn't a good enough reason.

But let my try again as well:

Deprecating           (oset object slot  value)
in favor of     (setf (oref object slot) value)
does *nothing* to increase "namespace sanity", the declared goal,
because while `oset' is now gone it has been replaced with `oref',
which lacks a prefix in exactly the same way, which meant the end
for `oset'.  At the same time this is worse because we now need
this additional boilerplate every time we set a slot:
                (setf                  )

I actually like `setf' (in other contexts) but I don't like that the
deprecation of `oset' forces me to use it here where it is more verbose
than what I used before.

I believe that a hypothetical attempt to deprecate `put' with the same
justification would fail because it would affect many people who would
protest against that move.  Fewer people protest the deprecation of
`oset' because fewer people use it in the first place.  I don't see how
the deprecation of `oset' is any more justified than the hypothetical
deprecation of `put'.

     Jonas

Re: Un-deprecating oset

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: Emacs developers <emacs-devel@gnu.org>
> Date: Sun, 24 May 2020 22:09:15 +0200
> 
> I wrote:
> > Stefan, we [...] now have heard a few additional voices that are
> > mildly in favor of keeping `oset'.  What's next?
> 
> and elsewhere Stefan replied:
> 
> > I don't plan to un-deprecate it (the discussion didn't bring up
> > any novel point from my point of view, so my opinion is the same
> > as before) unless Eli or John asks for it.
> 
> So I am now asking Eli and John to comment.

I tend to think it should be un-deprecated.

Re: Un-deprecating oset

[Stefan Monnier]

> 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`.


        Stefan

Re: Un-deprecating oset

[Eli Zaretskii]

> 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.

Re: Un-deprecating oset

[Basil L. Contovounesios]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-some-EIEIO-obsoletions.patch --]
[-- Type: text/x-diff, Size: 8834 bytes --]

From 5b6eedfee3ac95313d29dca57f56461322dd9b13 Mon Sep 17 00:00:00 2001
From: "Basil L. Contovounesios" <contovob@tcd.ie>
Date: Wed, 3 Jun 2020 14:18:19 +0100
Subject: [PATCH] Fix some EIEIO obsoletions

The deprecation of oset and oset-default was discussed in the
following threads:
https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00630.html
https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00674.html

* doc/misc/ede.texi (ede-generic-project): Tidy up example.
* doc/misc/eieio.texi (Accessing Slots): Document oref,
oref-default, and slot-value as generalized variables, and
set-slot-value as obsolete.  Consistently document getters before
setters.
(Predicates): Mention cl-print-object in place of the obsolete
object-print.
(Introspection): Document eieio-class-slots in place of the obsolete
object-slots.

* lisp/emacs-lisp/eieio.el: Un-deprecate oset and oset-default.
Make oref-default setf-able.
* etc/NEWS: Announce this change.

* test/lisp/emacs-lisp/eieio-tests/eieio-tests.el: Use
lexical-binding.
(eieio-test-13-init-methods): Simplify.
(eieio-test-33-instance-tracker): Declare IT-list as special.
---
 doc/misc/ede.texi                             | 10 ++--
 doc/misc/eieio.texi                           | 49 +++++++++++++------
 etc/NEWS                                      |  7 ++-
 lisp/emacs-lisp/eieio.el                      |  7 ++-
 .../emacs-lisp/eieio-tests/eieio-tests.el     |  5 +-
 5 files changed, 49 insertions(+), 29 deletions(-)

diff --git a/doc/misc/ede.texi b/doc/misc/ede.texi
index 584b0d7ee5..412176986c 100644
--- a/doc/misc/ede.texi
+++ b/doc/misc/ede.texi
@@ -955,18 +955,16 @@ ede-generic-project
 ;;; MAKEFILE
 
 (defclass ede-generic-makefile-project (ede-generic-project)
-  ((buildfile :initform "Makefile")
-   )
+  ((buildfile :initform "Makefile"))
   "Generic Project for makefiles.")
 
 (defmethod ede-generic-setup-configuration ((proj ede-generic-makefile-project) config)
-  "Setup a configuration for Make."
+  "Set up a configuration for Make."
   (oset config build-command "make -k")
-  (oset config debug-command "gdb ")
-  )
+  (oset config debug-command "gdb "))
 
 (ede-generic-new-autoloader "generic-makefile" "Make"
-			    "Makefile" 'ede-generic-makefile-project)
+                            "Makefile" 'ede-generic-makefile-project)
 @end example
 
 This example project will detect any directory with the file
diff --git a/doc/misc/eieio.texi b/doc/misc/eieio.texi
index 3943c544c7..06093f7263 100644
--- a/doc/misc/eieio.texi
+++ b/doc/misc/eieio.texi
@@ -698,6 +698,27 @@ Accessing Slots
 referencing vectors (@pxref{Vectors,,,elisp,GNU Emacs Lisp Reference
 Manual}).
 
+@defmac oref obj slot
+@anchor{oref}
+This macro retrieves the value stored in @var{obj} in the slot named
+by @var{slot}.  @var{slot} is the name of the slot when created by
+@dfn{defclass}.
+
+This is a generalized variable that can be used with @code{setf} to
+modify the value stored in @var{slot}.  @xref{Generalized
+Variables,,,elisp,GNU Emacs Lisp Reference Manual}.
+@end defmac
+
+@defmac oref-default class slot
+@anchor{oref-default}
+This macro returns the value of the class-allocated @var{slot} from
+@var{class}.
+
+This is a generalized variable that can be used with @code{setf} to
+modify the value stored in @var{slot}.  @xref{Generalized
+Variables,,,elisp,GNU Emacs Lisp Reference Manual}.
+@end defmac
+
 @defmac oset object slot value
 This macro sets the value behind @var{slot} to @var{value} in
 @var{object}.  It returns @var{value}.
@@ -716,17 +737,6 @@ Accessing Slots
 @end example
 @end defmac
 
-@defmac oref obj slot
-@anchor{oref}
-Retrieve the value stored in @var{obj} in the slot named by @var{slot}.
-Slot is the name of the slot when created by @dfn{defclass}.
-@end defmac
-
-@defmac oref-default class slot
-@anchor{oref-default}
-Get the value of the class-allocated @var{slot} from @var{class}.
-@end defmac
-
 The following accessors are defined by CLOS to reference or modify
 slot values, and use the previously mentioned set/ref routines.
 
@@ -734,14 +744,21 @@ Accessing Slots
 @anchor{slot-value}
 This function retrieves the value of @var{slot} from @var{object}.
 Unlike @code{oref}, the symbol for @var{slot} must be quoted.
+
+This is a generalized variable that can be used with @code{setf} to
+modify the value stored in @var{slot}.  @xref{Generalized
+Variables,,,elisp,GNU Emacs Lisp Reference Manual}.
 @end defun
 
 @defun set-slot-value object slot value
 @anchor{set-slot-value}
-This is not a CLOS function, but is the setter for @code{slot-value}
-used by the @code{setf} macro.  This
-function sets the value of @var{slot} from @var{object}.  Unlike
+This function sets the value of @var{slot} from @var{object}.  Unlike
 @code{oset}, the symbol for @var{slot} must be quoted.
+
+This is not a CLOS function, but is the obsolete setter for
+@code{slot-value} used by the @code{setf} macro.  It is therefore
+recommended to use @code{(setf (slot-value @var{object} @var{slot})
+@var{value})} instead.
 @end defun
 
 @defun slot-makeunbound object slot
@@ -1061,7 +1078,7 @@ Predicates
 Return a string of the form @samp{#<object-class myobjname>} for @var{obj}.
 This should look like Lisp symbols from other parts of Emacs such as
 buffers and processes, and is shorter and cleaner than printing the
-object's record.  It is more useful to use @code{object-print} to get
+object's record.  It is more useful to use @code{cl-print-object} to get
 and object's print form, as this allows the object to add extra display
 information into the symbol.
 @end defun
@@ -1217,7 +1234,7 @@ Introspection
 some functions have been provided.  None of these functions are a part
 of CLOS.
 
-@defun object-slots obj
+@defun eieio-class-slots obj
 Return the list of public slots for @var{obj}.
 @end defun
 
diff --git a/etc/NEWS b/etc/NEWS
index ed4722b27f..27e511047e 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -112,7 +112,12 @@ setting the variable 'auto-save-visited-mode' buffer-locally to nil.
 ** New bindings in occur-mode, 'next-error-no-select' bound to 'n' and
 'previous-error-no-select' bound to 'p'.
 
-** EIEIO: 'oset' and 'oset-default' are declared obsolete.
+** EIEIO
+
++++
+*** The macro 'oref-default' can now be used with 'setf'.
+It is now defined as a generalized variable that can be used with
+'setf' to modify the value stored in a given class slot.
 
 ** New minor mode 'cl-font-lock-built-in-mode' for `lisp-mode'.
 The mode provides refined highlighting of built-in functions, types,
diff --git a/lisp/emacs-lisp/eieio.el b/lisp/emacs-lisp/eieio.el
index ee5dd2cccd..73573a80eb 100644
--- a/lisp/emacs-lisp/eieio.el
+++ b/lisp/emacs-lisp/eieio.el
@@ -513,8 +513,7 @@ oset
   "Set the value in OBJ for slot SLOT to VALUE.
 SLOT is the slot name as specified in `defclass' or the tag created
 with in the :initarg slot.  VALUE can be any Lisp object."
-  (declare (obsolete "use (setf (oref ..) ..) instead" "28.1")
-           (debug (form symbolp form)))
+  (declare (debug (form symbolp form)))
   `(eieio-oset ,obj (quote ,slot) ,value))
 
 (defmacro oset-default (class slot value)
@@ -522,8 +521,7 @@ oset-default
 The default value is usually set with the :initform tag during class
 creation.  This allows users to change the default behavior of classes
 after they are created."
-  (declare (obsolete "use (setf (oref-default ..) ..) instead" "28.1")
-           (debug (form symbolp form)))
+  (declare (debug (form symbolp form)))
   `(eieio-oset-default ,class (quote ,slot) ,value))
 
 ;;; CLOS queries into classes and slots
@@ -654,6 +652,7 @@ object-remove-from-list
 ;; common code between oref and oset, so as to reduce the redundant work done
 ;; in (push foo (oref bar baz)), like we do for the `nth' expander?
 (gv-define-simple-setter eieio-oref eieio-oset)
+(gv-define-simple-setter eieio-oref-default eieio-oset-default)
 
 \f
 ;;;
diff --git a/test/lisp/emacs-lisp/eieio-tests/eieio-tests.el b/test/lisp/emacs-lisp/eieio-tests/eieio-tests.el
index 34c20b2003..21adc91e55 100644
--- a/test/lisp/emacs-lisp/eieio-tests/eieio-tests.el
+++ b/test/lisp/emacs-lisp/eieio-tests/eieio-tests.el
@@ -1,4 +1,4 @@
-;;; eieio-tests.el -- eieio tests routines
+;;; eieio-tests.el -- eieio test routines -*- lexical-binding: t -*-
 
 ;; Copyright (C) 1999-2003, 2005-2010, 2012-2020 Free Software
 ;; Foundation, Inc.
@@ -356,7 +356,7 @@ eieio-test-13-init-methods
     (oset a test-tag 1))
 
   (let ((ca (class-a)))
-    (should-not (/=  (oref ca test-tag) 2))))
+    (should (= (oref ca test-tag) 2))))
 
 \f
 ;;; Perform slot testing
@@ -852,6 +852,7 @@ IT
   "Instance Tracker test object.")
 
 (ert-deftest eieio-test-33-instance-tracker ()
+  (defvar IT-list)
   (let (IT-list IT1)
     (should (setq IT1 (IT)))
     ;; The instance tracker must find this
-- 
2.26.2

Re: Un-deprecating oset

[Basil L. Contovounesios]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

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

Here's an updated patch following an off-list suggestion by Stefan:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Un-deprecate-oset-and-oset-default.patch --]
[-- Type: text/x-diff, Size: 7318 bytes --]

From fc8b024116da65074a05a94f8f1983fe94aad8da Mon Sep 17 00:00:00 2001
From: "Basil L. Contovounesios" <contovob@tcd.ie>
Date: Wed, 3 Jun 2020 17:35:59 +0100
Subject: [PATCH] Un-deprecate oset and oset-default

For discussion see the following threads:
https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00630.html
https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00674.html
https://lists.gnu.org/archive/html/emacs-devel/2020-06/msg00099.html

* lisp/emacs-lisp/eieio.el (oset, oset-default): Un-deprecate.
* lisp/emacs-lisp/eieio-core.el (eieio-oref): Declare gv-setter here
instead of in lisp/emacs-lisp/eieio.el.  Suggested by
Stefan Monnier <monnier@iro.umontreal.ca>.
(eieio-oref-default): Add gv-setter declaration.
* etc/NEWS: Announce these changes.
* doc/misc/eieio.texi (Accessing Slots): Document oref and
oref-default as generalized variables.  Consistently document
getters before setters.
* test/lisp/emacs-lisp/eieio-tests/eieio-tests.el: Use
lexical-binding.
(eieio-test-13-init-methods): Simplify.
(eieio-test-33-instance-tracker): Declare IT-list as special.
---
 doc/misc/eieio.texi                           | 32 ++++++++++++-------
 etc/NEWS                                      |  7 +++-
 lisp/emacs-lisp/eieio-core.el                 |  4 ++-
 lisp/emacs-lisp/eieio.el                      | 14 ++------
 .../emacs-lisp/eieio-tests/eieio-tests.el     |  5 +--
 5 files changed, 35 insertions(+), 27 deletions(-)

diff --git a/doc/misc/eieio.texi b/doc/misc/eieio.texi
index 3943c544c7..9e6028d3de 100644
--- a/doc/misc/eieio.texi
+++ b/doc/misc/eieio.texi
@@ -698,6 +698,27 @@ Accessing Slots
 referencing vectors (@pxref{Vectors,,,elisp,GNU Emacs Lisp Reference
 Manual}).
 
+@defmac oref obj slot
+@anchor{oref}
+This macro retrieves the value stored in @var{obj} in the slot named
+by @var{slot}.  @var{slot} is the name of the slot when created by
+@dfn{defclass}.
+
+This is a generalized variable that can be used with @code{setf} to
+modify the value stored in @var{slot}.  @xref{Generalized
+Variables,,,elisp,GNU Emacs Lisp Reference Manual}.
+@end defmac
+
+@defmac oref-default class slot
+@anchor{oref-default}
+This macro returns the value of the class-allocated @var{slot} from
+@var{class}.
+
+This is a generalized variable that can be used with @code{setf} to
+modify the value stored in @var{slot}.  @xref{Generalized
+Variables,,,elisp,GNU Emacs Lisp Reference Manual}.
+@end defmac
+
 @defmac oset object slot value
 This macro sets the value behind @var{slot} to @var{value} in
 @var{object}.  It returns @var{value}.
@@ -716,17 +737,6 @@ Accessing Slots
 @end example
 @end defmac
 
-@defmac oref obj slot
-@anchor{oref}
-Retrieve the value stored in @var{obj} in the slot named by @var{slot}.
-Slot is the name of the slot when created by @dfn{defclass}.
-@end defmac
-
-@defmac oref-default class slot
-@anchor{oref-default}
-Get the value of the class-allocated @var{slot} from @var{class}.
-@end defmac
-
 The following accessors are defined by CLOS to reference or modify
 slot values, and use the previously mentioned set/ref routines.
 
diff --git a/etc/NEWS b/etc/NEWS
index ed4722b27f..27e511047e 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -112,7 +112,12 @@ setting the variable 'auto-save-visited-mode' buffer-locally to nil.
 ** New bindings in occur-mode, 'next-error-no-select' bound to 'n' and
 'previous-error-no-select' bound to 'p'.
 
-** EIEIO: 'oset' and 'oset-default' are declared obsolete.
+** EIEIO
+
++++
+*** The macro 'oref-default' can now be used with 'setf'.
+It is now defined as a generalized variable that can be used with
+'setf' to modify the value stored in a given class slot.
 
 ** New minor mode 'cl-font-lock-built-in-mode' for `lisp-mode'.
 The mode provides refined highlighting of built-in functions, types,
diff --git a/lisp/emacs-lisp/eieio-core.el b/lisp/emacs-lisp/eieio-core.el
index 1e53f30a2a..3bc65d0d4c 100644
--- a/lisp/emacs-lisp/eieio-core.el
+++ b/lisp/emacs-lisp/eieio-core.el
@@ -730,7 +730,8 @@ eieio-oref
                       (guard (not (memq name eieio--known-slot-names))))
                  (macroexp--warn-and-return
                   (format-message "Unknown slot `%S'" name) exp 'compile-only))
-                (_ exp)))))
+                (_ exp))))
+           (gv-setter eieio-oset))
   (cl-check-type slot symbol)
   (cl-check-type obj (or eieio-object class))
   (let* ((class (cond ((symbolp obj)
@@ -755,6 +756,7 @@ eieio-oref
 (defun eieio-oref-default (obj slot)
   "Do the work for the macro `oref-default' with similar parameters.
 Fills in OBJ's SLOT with its default value."
+  (declare (gv-setter eieio-oset-default))
   (cl-check-type obj (or eieio-object class))
   (cl-check-type slot symbol)
   (let* ((cl (cond ((symbolp obj) (cl--find-class obj))
diff --git a/lisp/emacs-lisp/eieio.el b/lisp/emacs-lisp/eieio.el
index ee5dd2cccd..b75410ee22 100644
--- a/lisp/emacs-lisp/eieio.el
+++ b/lisp/emacs-lisp/eieio.el
@@ -513,8 +513,7 @@ oset
   "Set the value in OBJ for slot SLOT to VALUE.
 SLOT is the slot name as specified in `defclass' or the tag created
 with in the :initarg slot.  VALUE can be any Lisp object."
-  (declare (obsolete "use (setf (oref ..) ..) instead" "28.1")
-           (debug (form symbolp form)))
+  (declare (debug (form symbolp form)))
   `(eieio-oset ,obj (quote ,slot) ,value))
 
 (defmacro oset-default (class slot value)
@@ -522,8 +521,7 @@ oset-default
 The default value is usually set with the :initform tag during class
 creation.  This allows users to change the default behavior of classes
 after they are created."
-  (declare (obsolete "use (setf (oref-default ..) ..) instead" "28.1")
-           (debug (form symbolp form)))
+  (declare (debug (form symbolp form)))
   `(eieio-oset-default ,class (quote ,slot) ,value))
 
 ;;; CLOS queries into classes and slots
@@ -647,14 +645,6 @@ object-remove-from-list
       nil
     (eieio-oset object slot (delete item (eieio-oref object slot)))))
 
-;;; Here are some CLOS items that need the CL package
-;;
-
-;; FIXME: Shouldn't this be a more complex gv-expander which extracts the
-;; common code between oref and oset, so as to reduce the redundant work done
-;; in (push foo (oref bar baz)), like we do for the `nth' expander?
-(gv-define-simple-setter eieio-oref eieio-oset)
-
 \f
 ;;;
 ;; We want all objects created by EIEIO to have some default set of
diff --git a/test/lisp/emacs-lisp/eieio-tests/eieio-tests.el b/test/lisp/emacs-lisp/eieio-tests/eieio-tests.el
index 34c20b2003..21adc91e55 100644
--- a/test/lisp/emacs-lisp/eieio-tests/eieio-tests.el
+++ b/test/lisp/emacs-lisp/eieio-tests/eieio-tests.el
@@ -1,4 +1,4 @@
-;;; eieio-tests.el -- eieio tests routines
+;;; eieio-tests.el -- eieio test routines -*- lexical-binding: t -*-
 
 ;; Copyright (C) 1999-2003, 2005-2010, 2012-2020 Free Software
 ;; Foundation, Inc.
@@ -356,7 +356,7 @@ eieio-test-13-init-methods
     (oset a test-tag 1))
 
   (let ((ca (class-a)))
-    (should-not (/=  (oref ca test-tag) 2))))
+    (should (= (oref ca test-tag) 2))))
 
 \f
 ;;; Perform slot testing
@@ -852,6 +852,7 @@ IT
   "Instance Tracker test object.")
 
 (ert-deftest eieio-test-33-instance-tracker ()
+  (defvar IT-list)
   (let (IT-list IT1)
     (should (setq IT1 (IT)))
     ;; The instance tracker must find this
-- 
2.26.2


[-- Attachment #3: Type: text/plain, Size: 144 bytes --]


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

And here's a separate patch for the changes that can go into emacs-27:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0001-Minor-improvements-to-EDE-and-EIEIO-manuals.patch --]
[-- Type: text/x-diff, Size: 3601 bytes --]

From 2421e4534646cfd49f6e701359826f31c9d351fc Mon Sep 17 00:00:00 2001
From: "Basil L. Contovounesios" <contovob@tcd.ie>
Date: Wed, 3 Jun 2020 17:31:44 +0100
Subject: [PATCH] Minor improvements to EDE and EIEIO manuals

For discussion, see the following threads:
https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00630.html
https://lists.gnu.org/archive/html/emacs-devel/2020-06/msg00099.html

* doc/misc/ede.texi (ede-generic-project): Clean up example.
* doc/misc/eieio.texi (Accessing Slots): Document slot-value as a
generalized variable and set-slot-value as obsolete.
(Predicates): Fix typo.
(Introspection): Document eieio-class-slots in place of the obsolete
object-slots.
---
 doc/misc/ede.texi   | 10 ++++------
 doc/misc/eieio.texi | 17 ++++++++++++-----
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/doc/misc/ede.texi b/doc/misc/ede.texi
index 584b0d7ee5..412176986c 100644
--- a/doc/misc/ede.texi
+++ b/doc/misc/ede.texi
@@ -955,18 +955,16 @@ ede-generic-project
 ;;; MAKEFILE
 
 (defclass ede-generic-makefile-project (ede-generic-project)
-  ((buildfile :initform "Makefile")
-   )
+  ((buildfile :initform "Makefile"))
   "Generic Project for makefiles.")
 
 (defmethod ede-generic-setup-configuration ((proj ede-generic-makefile-project) config)
-  "Setup a configuration for Make."
+  "Set up a configuration for Make."
   (oset config build-command "make -k")
-  (oset config debug-command "gdb ")
-  )
+  (oset config debug-command "gdb "))
 
 (ede-generic-new-autoloader "generic-makefile" "Make"
-			    "Makefile" 'ede-generic-makefile-project)
+                            "Makefile" 'ede-generic-makefile-project)
 @end example
 
 This example project will detect any directory with the file
diff --git a/doc/misc/eieio.texi b/doc/misc/eieio.texi
index 3943c544c7..aceaff051e 100644
--- a/doc/misc/eieio.texi
+++ b/doc/misc/eieio.texi
@@ -734,14 +734,21 @@ Accessing Slots
 @anchor{slot-value}
 This function retrieves the value of @var{slot} from @var{object}.
 Unlike @code{oref}, the symbol for @var{slot} must be quoted.
+
+This is a generalized variable that can be used with @code{setf} to
+modify the value stored in @var{slot}.  @xref{Generalized
+Variables,,,elisp,GNU Emacs Lisp Reference Manual}.
 @end defun
 
 @defun set-slot-value object slot value
 @anchor{set-slot-value}
-This is not a CLOS function, but is the setter for @code{slot-value}
-used by the @code{setf} macro.  This
-function sets the value of @var{slot} from @var{object}.  Unlike
+This function sets the value of @var{slot} from @var{object}.  Unlike
 @code{oset}, the symbol for @var{slot} must be quoted.
+
+This is not a CLOS function, but is the obsolete setter for
+@code{slot-value} used by the @code{setf} macro.  It is therefore
+recommended to use @w{@code{(setf (slot-value @var{object} @var{slot})
+@var{value})}} instead.
 @end defun
 
 @defun slot-makeunbound object slot
@@ -1062,7 +1069,7 @@ Predicates
 This should look like Lisp symbols from other parts of Emacs such as
 buffers and processes, and is shorter and cleaner than printing the
 object's record.  It is more useful to use @code{object-print} to get
-and object's print form, as this allows the object to add extra display
+an object's print form, as this allows the object to add extra display
 information into the symbol.
 @end defun
 
@@ -1217,7 +1224,7 @@ Introspection
 some functions have been provided.  None of these functions are a part
 of CLOS.
 
-@defun object-slots obj
+@defun eieio-class-slots obj
 Return the list of public slots for @var{obj}.
 @end defun
 
-- 
2.26.2


[-- Attachment #5: Type: text/plain, Size: 11 bytes --]


-- 
Basil

Re: Un-deprecating oset

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  jonas@bernoul.li,
>   johnw@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 03 Jun 2020 18:03:53 +0100
> 
> +@defmac oref obj slot
> +@anchor{oref}
> +This macro retrieves the value stored in @var{obj} in the slot named
> +by @var{slot}.  @var{slot} is the name of the slot when created by
> +@dfn{defclass}.

Two minor stylistic points:

 . It is many times better to use the argument name as an integral
   part of the sentence, instead of separating it.  For example:

    This macro retrieves the value stored in @var{obj} in the named
    @var{slot}.

 . It is better to avoid starting a sentence with @var{something},
   because in the printed version of the manual @var{..} doesn't
   capitalize its argument, so you get a sentence that starts with a
   lower-case letter, which is not valid English.  (Yes, we have a lot
   of examples of this sub-optimal usage our manuals.)  In this case,
   I would rephrase:

    Slots names are determined by @dfn{defclass} which creates the
    slot.

Btw, why is "defclass" in @dfn here?

Thanks.

Re: Un-deprecating oset

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  jonas@bernoul.li,
>>   johnw@gnu.org,  emacs-devel@gnu.org
>> Date: Wed, 03 Jun 2020 18:03:53 +0100
>> 
>> +@defmac oref obj slot
>> +@anchor{oref}
>> +This macro retrieves the value stored in @var{obj} in the slot named
>> +by @var{slot}.  @var{slot} is the name of the slot when created by
>> +@dfn{defclass}.
>
> Two minor stylistic points:

Thanks, I incorporated your suggestions and pushed the two patches to
master and emacs-27, respectively.

Un-deprecate oset and oset-default
8bcc781bc7 2020-06-06 17:24:00 +0100
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8bcc781bc762b4082cfd678b88938e3d03465d91

Minor improvements to EDE and EIEIO manuals
d8593fd19f 2020-06-06 16:35:52 +0100
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d8593fd19ffdb1fa62f0b0c4b971cfdb325fbe1d

>  . It is many times better to use the argument name as an integral
>    part of the sentence, instead of separating it.  For example:
>
>     This macro retrieves the value stored in @var{obj} in the named
>     @var{slot}.
>
>  . It is better to avoid starting a sentence with @var{something},
>    because in the printed version of the manual @var{..} doesn't
>    capitalize its argument, so you get a sentence that starts with a
>    lower-case letter, which is not valid English.  (Yes, we have a lot
>    of examples of this sub-optimal usage our manuals.)  In this case,
>    I would rephrase:
>
>     Slots names are determined by @dfn{defclass} which creates the
>     slot.
>
> Btw, why is "defclass" in @dfn here?

I saw no reason for it so changed it to @code instead.

Thanks,

-- 
Basil

Re: Un-deprecating oset

[Jonas Bernoulli]

Thanks again!

Re: Un-deprecating oset

[Jonas Bernoulli]

> 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

FWIW I originally didn't like that move either but am now totally behind
it.  And while I haven't been consistently prefixing all symbols in all
of my own packages, I am coming around here too.  (I did whine a little
when you raised concerns about the prefix-less symbols in Transient, but
have fixed that now and think it is for the better.)

Just mentioning these things (again) so you don't feel like you are up
against someone who opposes the use of package prefixes on principle.

Like Eli I support the whole prefixing endeavor, but feel like there
should be exceptions and apparently I feel pretty strongly that this
ought to be one of those.  ;D

> It seems rather odd that `defclass` is allowed into the core namespace
> while `defstruct` had to be relegated to `cl-defstruct`.

I was wondering about that too, it always seemed like an oversight
to me.  It makes even less sense if you consider `cl-defgeneric'
and `cl-defmethod'.

     Jonas