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 <address@hidden> 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.