From: Jonas Bernoulli <jonas@bernoul.li>
To: emacs-devel@gnu.org
Subject: Un-deprecating oset
Date: Tue, 05 May 2020 12:34:37 +0200 [thread overview]
Message-ID: <87eery1xhe.fsf@bernoul.li> (raw)
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.
next reply other threads:[~2020-05-05 10:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-05 10:34 Jonas Bernoulli [this message]
2020-05-05 10:48 ` Un-deprecating oset Philippe Vaucher
2020-05-05 11:11 ` Basil L. Contovounesios
2020-05-05 14:50 ` Stefan Monnier
2020-05-12 15:06 ` Jonas Bernoulli
2020-05-12 16:49 ` Philippe Vaucher
2020-05-12 21:47 ` Adam Porter
2020-05-13 13:04 ` Philipp Stephani
2020-05-14 7:50 ` Juanma Barranquero
2020-05-14 12:13 ` Basil L. Contovounesios
2020-05-14 12:31 ` Juanma Barranquero
2020-05-17 21:19 ` Jonas Bernoulli
2020-05-24 20:09 ` Jonas Bernoulli
2020-05-25 15:21 ` Eli Zaretskii
2020-05-25 16:06 ` Stefan Monnier
2020-05-25 16:25 ` Eli Zaretskii
2020-06-03 14:03 ` Basil L. Contovounesios
2020-06-03 17:03 ` Basil L. Contovounesios
2020-06-06 7:38 ` Eli Zaretskii
2020-06-06 16:43 ` Basil L. Contovounesios
2020-06-08 12:42 ` Jonas Bernoulli
2020-05-25 17:27 ` Jonas Bernoulli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eery1xhe.fsf@bernoul.li \
--to=jonas@bernoul.li \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).