Obsoleting more progressively

Obsoleting more progressively

[Stefan Monnier]

`make-obsolete' and friends are very useful to let us get rid of old
features, but even after 10 years of something being declared obsolete,
experience shows it's still in use "out there".
So I'd like to be able to make things "more obsolete" (i.e. create
a second level of obsolescence) before we actually remove them.

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.
  For hooks, we could let add-hook check the obsolescence property and
  emit a warning, and similarly for a few difference cases, but for
  the primitive get&set operations, this is not an option.
- 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.

Any thoughts?

  
        Stefan

Re: Obsoleting more progressively

[Lennart Borgman]

On Tue, Nov 2, 2010 at 4:10 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> `make-obsolete' and friends are very useful to let us get rid of old
> features, but even after 10 years of something being declared obsolete,
> experience shows it's still in use "out there".
> So I'd like to be able to make things "more obsolete" (i.e. create
> a second level of obsolescence) before we actually remove them.
>
> 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.
>  For hooks, we could let add-hook check the obsolescence property and
>  emit a warning, and similarly for a few difference cases, but for
>  the primitive get&set operations, this is not an option.
> - 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.


Actually removing them during development seems to create less trouble to me.

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.

RE: Obsoleting more progressively

[Drew Adams]

SM> `make-obsolete' and friends are very useful to let us get rid of old
SM> features, but even after 10 years of something being declared 
SM> obsolete, experience shows it's still in use "out there".

Don't worry about it "out there".  Worry about it only "in here".  Worry only
about the code that you produce: the vanilla Emacs sources.

There are sometimes good reasons why code "out there" can continue to reference
constructs that have been declared obsolete.  Code that needs to work with
multiple Emacs releases can contain such constructs and can even sometimes
access some of them during runtime, sometimes even in a version where the
construct is obsolete.

That's at least possible, given the dynamic nature of Lisp code (including code
generation).  And it's not necessarily a problem if it happens.

And code "out there" can also contain constructs that happen to have the same
names etc. as vanilla constructs that have been declared obsolete.  There is no
way to automatically analyze code (static or running) to determine whether
something is actually an obsolete construct and, if so, whether its use is
actually problematic.

Even when there are _no_ good reasons for particular code "out there" to use an
obsolete construct, that does not mean that there is necessarily a problem.  And
it certainly does not mean that _you_ need to do anything about it, beyond
declaring the obsolescence.

Please do not even think about imposing runtime "warnings" about things you
consider obsolete.

So much for what you should not do.  What you should do:

Make clear what you consider deprecated or obsolete.  Make it easy (e.g.
compile-time info) for 3rd-party developers and users to find obsolete
constructs in their code.  That's all.

Leave it up to them how to handle those constructs in their code: whether to
remove them etc.

ST> runtime warnings would severely piss off users (...), enough so
ST> that actively maintained packages would quickly upgrade.

What a wonderful approach that would be.

Re: Obsoleting more progressively

[jasonr]

Quoting Stefan Monnier <monnier@IRO.UMontreal.CA>:

> 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.
>   For hooks, we could let add-hook check the obsolescence property and
>   emit a warning, and similarly for a few difference cases, but for
>   the primitive get&set operations, this is not an option.
> - 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.
>
> Any thoughts?

Another possibility is to leave the elisp there, but needing some explicit
action to load it. Maybe a new function (load-obsolete "file") to load such
files, or (use-obsolete 'feature) to enable loading that feature with the usual
functions. This assumes whole files that have been obsoleted - if it is the odd
variable or function within a still current package, then they should probably
be moved to a new file in the obsolete directory first.

Re: Obsoleting more progressively

[Stefan Monnier]

> Another possibility is to leave the elisp there, but needing some
> explicit action to load it. Maybe a new function (load-obsolete
> "file") to load such files, or (use-obsolete 'feature) to enable
> loading that feature with the usual functions. This assumes whole
> files that have been obsoleted - if it is the odd variable or function
> within a still current package, then they should probably be moved to
> a new file in the obsolete directory first.

I'm more concerned about "the odd variable or function", but that's
a good idea: we could rename the var/function to "obsolete-<foo>", so
that a simple (defalias/defvaralias '<foo> 'obsolete-<foo>) brings it back.


        Stefan

Re: Obsoleting more progressively

[CHENG Gao]

I think some rules need be set about when to remove obsolete
functions/variables. For example some rule like MAJOR VERSION -1 or -2.
That's to say when EMACS 24 is under development/released, all obsolete
functions/variables since 23 or 22 will be removed. Sure this number can
be discussed and then decided. Personally I think 1 or 2 is reasonable.

Re: Obsoleting more progressively

[Leo]

On 2010-11-03 10:58 +0800, CHENG Gao wrote:
> I think some rules need be set about when to remove obsolete
> functions/variables. For example some rule like MAJOR VERSION -1 or -2.
> That's to say when EMACS 24 is under development/released, all obsolete
> functions/variables since 23 or 22 will be removed. Sure this number can
> be discussed and then decided. Personally I think 1 or 2 is reasonable.

I think I like this too.

Leo

Re: Obsoleting more progressively

[Andreas Röhler]

Am 02.11.2010 16:10, schrieb Stefan Monnier:
> `make-obsolete' and friends are very useful to let us get rid of old
> features, but even after 10 years of something being declared obsolete,
> experience shows it's still in use "out there".
> So I'd like to be able to make things "more obsolete" (i.e. create
> a second level of obsolescence) before we actually remove them.
>
> 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.
>    For hooks, we could let add-hook check the obsolescence property and
>    emit a warning, and similarly for a few difference cases, but for
>    the primitive get&set operations, this is not an option.
> - 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.
>
> Any thoughts?
>
>
>          Stefan
>
>

Hi Stefan,

IMHO that would make things more complicated but don't solve the issue.

The issue is to establish a consistent rule what to do with `obsolete' 
marked forms.

As from my limited perspective, it's quite simple:
don't allow them in new code.

Should someone insist, maybe remove `obsolete' again, as it might have 
been an error.

Else remove the forms in old code.
So cure the problem rather than augmenting warnings.

Thanks


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/

Re: Obsoleting more progressively

[Glenn Morris]

FWIW, I suspect much of the problem you are trying to solve is due to
no-one paying attention to the warnings. Either because the package is
unmaintained but still in use, so there is no-one there to deal with
the warnings (eg recent old-style backquotes stuff), in which case
trying to make it fail more gradually makes no difference to the final
result; or because people just ignore the warnings.

So I agree with the suggestion that the best way to deal with this is
to make the warnings _mean_ something; ie actually remove obsolete
stuff in a timely fashion, not drag it out for still longer.

Anyway, having said that:

Stefan Monnier wrote:

> - Add warnings at runtime when obsolete stuff is used.

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

You could combine 1 with 2 by having some flag that says whether using
an obsolete thing triggers an error or a warning. Set it to error
during development, and to warning for a release.

Un-thought-out plan: when compiling foo.el, put a comment marker at
the end of the file giving the obsolescence version of the oldest
obsolete feature that it uses (if any).

When loading foo.elc, give an error or warning if the marker indicates
that a very obsolete feature is used (Eg "This file uses features that
were obsolete in Emacs 21"). Disable the warning if foo.el has been
added to some list variable
i-know-that-this-file-uses-obsolete-code-and-will-break-soon. (If it
is controlled by a global switch people will just turn it off and
forget about it.)

Comedy option: parse foo.el for a maintainer address, have the
byte-compiler spam the maintainer every time the file is compiled.

Re: Obsoleting more progressively

[Kan-Ru Chen]

Andreas Röhler <andreas.roehler@online.de> writes:

> Hi Stefan,
>
> IMHO that would make things more complicated but don't solve the issue.
>
> The issue is to establish a consistent rule what to do with `obsolete'
> marked forms.
>
> As from my limited perspective, it's quite simple:
> don't allow them in new code.

Agree. Maybe deactivate the obsolete symbol and require explicit
declaration for code that want to use the symbol, before it actually got
removed.

-- 
A badly written book is only a blunder. A bad translation of a good
book is a crime.
                -- Gilbert Highet

Re: Obsoleting more progressively

[Stefan Monnier]

> FWIW, I suspect much of the problem you are trying to solve is due to
> no-one paying attention to the warnings.

Yes, currently the obsolescence info is only displayed in docstrings and
in byte-compiler warnings.  So it's relatively easy for a piece of
oldish code to spend 10 years without anyone seeing these (except for
people who can't do much about it and are just happy that it still
works).

> Either because the package is unmaintained but still in use, so there
> is no-one there to deal with the warnings (eg recent old-style
> backquotes stuff), in which case trying to make it fail more gradually
> makes no difference to the final result; or because people just ignore
> the warnings.

My expectation is that if we make it half-break after 5 years (say), we
might expect that someone will fix it in less than 5 years, so that
after a total of 10 years noone will suffer when we actually remove
the feature.

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

> You could combine 1 with 2 by having some flag that says whether using
> an obsolete thing triggers an error or a warning. Set it to error
> during development, and to warning for a release.

I currently like the obsolete-<foo> renaming suggestion.  We can then
provide commands (or even a Custom var) to add the necessary aliasing to
make it work, and those vars/commands can very well emit a warning at
startup.

> Un-thought-out plan: when compiling foo.el, put a comment marker at
> the end of the file giving the obsolescence version of the oldest
> obsolete feature that it uses (if any).

That won't help people who're using a .elc (or even a .el) file they
got 15 years ago.


        Stefan