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