Obsoleting more progressively

[Stephen J. Turnbull]

Stefan Monnier writes:

 > I can think of 2 ways to do implement that second level of obsolescence:
 > - Add warnings at runtime when obsolete stuff is used.
 >   for functions, commands and macros, make-obsolete that's reasonably
 >   easy to do; for variables it's more difficult.

It's not impossible, though.  Move them into C and given them a magic
"forwarding" value that triggers a warning and then returns or sets
the real value.  (It would also be possible to do this at the LISP
level with appropriate LISP primitives, I guess.  That way the
forwarding value can't leak out.)

I would imagine that runtime warnings would severely piss off users
(hi, Eli! what was that you were saying over on the bazaar list?),
enough so that actively maintained packages would quickly upgrade.
But is it worth the burden that would be imposed on users of
dormant/defunct projects?

Also, although the forwarding mechanism would impose a slight
performance cost on every variable access, this penalty would only be
substantial for variables that are actually obsolete.  Still it might
be unacceptable.

 > - Actually remove the function/variable from the non-released code.
 >   I.e. remove/deactivate the functions/variables from trunk during
 >   development but put them back in when we start pretesting.

Yuck.  Sounds like a wonderful way to lengthen the pretest period, to
me.