Obsolete functions and variables

Obsolete functions and variables

[Nick Roberts]

On the trunk, would now be a good time to remove all the functions and
variables that were made obsolete in 22.1?  This would give a resonable time
frame for users of Emacs in CVS to adjust their packages before the next
mainline release.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Obsolete functions and variables

[Juanma Barranquero]

>  On the trunk, would now be a good time to remove all the functions and
>  variables that were made obsolete in 22.1?

We haven't removed things obsoleted way before, like `baud-rate',
`unread-command-char', `executing-macro', `char-bytes',
`set-screen-width', `set-screen-height'. Perhaps we could start by
removing some of these.

 Juanma

Re: Obsolete functions and variables

[Richard Stallman]

    We haven't removed things obsoleted way before, like `baud-rate',
    `unread-command-char', `executing-macro', `char-bytes',
    `set-screen-width', `set-screen-height'. Perhaps we could start by
    removing some of these.

Removing them, even after many years, could break some programs
that people have not updated.  Be careful!

Re: Obsolete functions and variables

[Juanma Barranquero]

On Thu, Apr 10, 2008 at 5:31 PM, Richard Stallman <rms@gnu.org> wrote:

>  Removing them, even after many years, could break some programs
>  that people have not updated.  Be careful!

I'm nog going to remove any of them. I should confess that my remark
was ironic, because I knew Nick was being way too optimistic...

 Juanma

Re: Obsolete functions and variables

[Nick Roberts]

Juanma Barranquero writes:
 > On Thu, Apr 10, 2008 at 5:31 PM, Richard Stallman <rms@gnu.org> wrote:
 > 
 > >  Removing them, even after many years, could break some programs
 > >  that people have not updated.  Be careful!
 > 
 > I'm nog going to remove any of them. I should confess that my remark
 > was ironic, because I knew Nick was being way too optimistic...

Maybe it was flippant but I don't see any irony.  Perhaps obsolete functions
and variables should only be removed after two major releases.  I guess
the dangers generally outweigh the advantages but there's not much point in
marking them obsolete if they're never going to be removed.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Obsolete functions and variables

[Juanma Barranquero]

On Fri, Apr 11, 2008 at 12:53 AM, Nick Roberts <nickrob@snap.net.nz> wrote:

>  I guess
>  the dangers generally outweigh the advantages but there's not much point in
>  marking them obsolete if they're never going to be removed.

I agree. I just don't expect it to happen.

 Juanma

Re: Obsolete functions and variables

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Fri, Apr 11, 2008 at 12:53 AM, Nick Roberts <nickrob@snap.net.nz> wrote:
> 
>>  I guess
>>  the dangers generally outweigh the advantages but there's not much point in
>>  marking them obsolete if they're never going to be removed.
> 
> I agree. I just don't expect it to happen.


I am not sure I agree. Are not a function sometimes marked as obsolete 
because there is a new better version that works in more cases? The old 
obsolete function may still work in many cases.

Maybe a more visible warning when obsolete things are found would be 
good? (Using for example lwarn.)

Re: Obsolete functions and variables

[Nick Roberts]

 > >>  I guess the dangers generally outweigh the advantages but there's not
 > >>  much point in marking them obsolete if they're never going to be
 > >>  removed.
 > > 
 > > I agree. I just don't expect it to happen.
 > 
 > 
 > I am not sure I agree. Are not a function sometimes marked as obsolete 
 > because there is a new better version that works in more cases? The old 
 > obsolete function may still work in many cases.

  Obsolete \Ob"so*lete\, a. [L. obsoletus, p. p. of obsolescere.
     See {Obsolescent}.]
     1. No longer in use; gone into disuse; disused; neglected;

Hmm, this is starting to sound like Monty Python's dead parrot sketch!

 > Maybe a more visible warning when obsolete things are found would be 
 > good? (Using for example lwarn.)

How would this work?  Not in some hand wavy way but with a real code
explanation.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Obsolete functions and variables

[Lennart Borgman (gmail)]

Nick Roberts wrote:
>  > >>  I guess the dangers generally outweigh the advantages but there's not
>  > >>  much point in marking them obsolete if they're never going to be
>  > >>  removed.
>  > > 
>  > > I agree. I just don't expect it to happen.
>  > 
>  > 
>  > I am not sure I agree. Are not a function sometimes marked as obsolete 
>  > because there is a new better version that works in more cases? The old 
>  > obsolete function may still work in many cases.
> 
>   Obsolete \Ob"so*lete\, a. [L. obsoletus, p. p. of obsolescere.
>      See {Obsolescent}.]
>      1. No longer in use; gone into disuse; disused; neglected;
> 
> Hmm, this is starting to sound like Monty Python's dead parrot sketch!

I am glad we are creative.

>  > Maybe a more visible warning when obsolete things are found would be 
>  > good? (Using for example lwarn.)
> 
> How would this work?  Not in some hand wavy way but with a real code
> explanation.

Do you mean it is difficult to do this? After looking at the code I 
might think it is. I thought that eval warned about obsolete functions 
but it does not. I do not think eval cares about "obsolete-ness". It is 
the bytecompiler that does it and the warnings given by the byte 
compiler are rather visible, but they does not explain very much.

Maybe a comment at the end of the compilation log could tell people to 
remove the use of obsolete things?

Re: Obsolete functions and variables

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

On Fri, 11 Apr 2008 11:45:50 +1200
Nick Roberts <nickrob@snap.net.nz> wrote:

>  > >>  I guess the dangers generally outweigh the advantages but
>  > >> there's not much point in marking them obsolete if they're
>  > >> never going to be removed.
>  > > 
>  > > I agree. I just don't expect it to happen.
>  > 
>  > 
>  > I am not sure I agree. Are not a function sometimes marked as
>  > obsolete because there is a new better version that works in more
>  > cases? The old obsolete function may still work in many cases.
> 
>   Obsolete \Ob"so*lete\, a. [L. obsoletus, p. p. of obsolescere.
>      See {Obsolescent}.]
>      1. No longer in use; gone into disuse; disused; neglected;
> 
> Hmm, this is starting to sound like Monty Python's dead parrot sketch!
> 
>  > Maybe a more visible warning when obsolete things are found would
>  > be good? (Using for example lwarn.)
> 
> How would this work?  Not in some hand wavy way but with a real code
> explanation.
> 

If I need something really visible I inject it into the scratch buffer
as a comment. I Never miss that.

Cheers,
Mike Mattie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Obsolete functions and variables

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

On Fri, 11 Apr 2008 01:27:57 +0200
"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> wrote:

> Juanma Barranquero wrote:
> > On Fri, Apr 11, 2008 at 12:53 AM, Nick Roberts
> > <nickrob@snap.net.nz> wrote:
> > 
> >>  I guess
> >>  the dangers generally outweigh the advantages but there's not
> >> much point in marking them obsolete if they're never going to be
> >> removed.
> > 
> > I agree. I just don't expect it to happen.
> 
> 
> I am not sure I agree. Are not a function sometimes marked as
> obsolete because there is a new better version that works in more
> cases? The old obsolete function may still work in many cases.
> 
> Maybe a more visible warning when obsolete things are found would be 
> good? (Using for example lwarn.)

A mention of a URL, or the information to fix it would be a help.

This was a jewel for figuring out what old style back-quotes are.

http://iep.water.ca.gov/d/bin/sbin/site/lib/xemacs-19.15/lisp/prim/backquote.el

CA Department of Water Resources Interagency Ecological Program (I.E.P) was not my first
thought to find such a useful Emacs document.

This file had a very good explanation. I know you can always google, but google
is getting less useful it seems: to many hits on web-forums and portals.

> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Obsolete functions and variables

[Stefan Monnier]

>> >  Removing them, even after many years, could break some programs
>> >  that people have not updated.  Be careful!
>> 
>> I'm nog going to remove any of them. I should confess that my remark
>> was ironic, because I knew Nick was being way too optimistic...

> Maybe it was flippant but I don't see any irony.  Perhaps obsolete functions
> and variables should only be removed after two major releases.  I guess
> the dangers generally outweigh the advantages but there's not much point in
> marking them obsolete if they're never going to be removed.

Usually, we look at the obsolete vars&funs, select the really old ones
(e.g. the ones that are obsolete since 20.7 or maybe even 21.1) and then
check which of these can be safely removed.

BTW, could someone update the obsolete/*.el packages by adding in the
header an indication about the release in which they were made obsolete?


        Stefan

Re: Obsolete functions and variables

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Usually, we look at the obsolete vars&funs, select the really old ones
 > (e.g. the ones that are obsolete since 20.7 or maybe even 21.1) and then
 > check which of these can be safely removed.

FWIW Python has been successfully deprecating and removing identifiers
for about a decade.  They warn for maybe one or two release cycles
(ie, in an x.y.z scheme, from x.y.z to x.y+2.0), then the obsolete
name gets a one-way ticket to a senior community in Arizona.

However, they also support a full release cycle older than the current
release, plus security updates (source-only) for two release cycles
before that.

Re: Obsolete functions and variables

[Richard Stallman]

      I guess
    the dangers generally outweigh the advantages but there's not much point in
    marking them obsolete if they're never going to be removed.

I think that is incorrect.  It is useful to urge people to make their
code use more modern interfaces regardless of whether we ever delete
the old ones.

Re: Obsolete functions and variables

[Sebastian Rose]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

Richard Stallman schrieb:
>       I guess
>     the dangers generally outweigh the advantages but there's not much point in
>     marking them obsolete if they're never going to be removed.
> 
> I think that is incorrect.  It is useful to urge people to make their
> code use more modern interfaces regardless of whether we ever delete
> the old ones.
> 
> 

# cd emacs/lisp/ext/bbdbb-2.35
# ./configure --enable-gnus
# make

In toplevel form:
bbdb-whois.el:25:1:Warning: !! The file uses old-style backquotes !!
This functionality has been obsolete for more than 10 years already
and will be removed soon.  See (elisp)Backquote in the manual.

:-)

[-- Attachment #2: sebastian_rose.vcf --]
[-- Type: text/x-vcard, Size: 499 bytes --]

begin:vcard
fn:Sebastian Rose
n:Rose;Sebastian
email;internet:sebastian_rose@gmx.de
title:Fachinformatiker/Anwendendungsentwicklung
tel;cell:+49 173 / 83 93 417
note;quoted-printable:Entwicklung  von Internetanwendungen und Programmen  mit  freien  Werkzeu=
	gen  und Bibliotheken.=0D=0A=
	=0D=0A=
	PHP, Java, C/C++,  Bash,  Perl,  Apache, MySQL,  PostgreSQL, xt::commerce=
	, Typo3, Server,  Netzwerk,  Desktop, Datenbank, gtkmm=0D=0A=
	
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: Obsolete functions and variables

[Nick Roberts]

 >       I guess the dangers generally outweigh the advantages but there's not
 >     much point in marking them obsolete if they're never going to be
 >     removed.
 > 
 > I think that is incorrect.  It is useful to urge people to make their
 > code use more modern interfaces regardless of whether we ever delete
 > the old ones.

In that case, perhaps the macros should have been called
define-deprecated-variable-alias and define-deprecated-function-alias.  The
word obsolete has a pretty clear meaning and is misleading when used in this
way.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Obsolete functions and variables

[Stefan Monnier]

> In that case, perhaps the macros should have been called
> define-deprecated-variable-alias and define-deprecated-function-alias.
> The word obsolete has a pretty clear meaning and is misleading when
> used in this way.

The intention is to remove them.  But the way it works, basically is:
mark it as obsolete.  Which in turn makes people stop using them, and
when people have stopped using them, we can remove them.
It may take a *long* time for people to stop using them.

And it may happen that people don't stop using them because the
alternatives aren't really good enough, in which case we may need to
improve the new interface, or we may need to de-obsolete
the functionality.  It may also happen that people don't stop using them
because they want to stay compatible with XEmacs and that XEmacs has
decided to not support the new interface.  But the intention is still
the same: a functionality marked as "obsolete" is scheduled for removal.

Can we close this discussion?  A more useful one would be to do the work
of checking obsoleted functions/variables/packages and see which ones
can be removed because they're not used any more.


        Stefan

Re: Obsolete functions and variables

[Nick Roberts]

 > Can we close this discussion?  A more useful one would be to do the work
 > of checking obsoleted functions/variables/packages and see which ones
 > can be removed because they're not used any more.

Which is impossible, of course, as there are many packages such as JDEE, ECB
and Cedet which might use them. The only time we'll know if they are still
used is after their removal when someone complains.

If ten years of byte compiler warnings stating that a variable is obsolete is
not enough to justify its removal, I'll probably spend less time on dealing
with them, not more.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Obsolete functions and variables

[Stefan Monnier]

>> Can we close this discussion?  A more useful one would be to do the work
>> of checking obsoleted functions/variables/packages and see which ones
>> can be removed because they're not used any more.

> Which is impossible, of course, as there are many packages such as JDEE, ECB
> and Cedet which might use them.

Yes, we usually try and check them to get an idea for whether they're
still used.

> The only time we'll know if they are still used is after their removal
> when someone complains.

Yes, we don't need to be 100% sure that they're not used any more.

> If ten years of byte compiler warnings stating that a variable is obsolete is
> not enough to justify its removal, I'll probably spend less time on dealing
> with them, not more.

Yes, there's no need to spend much time on it.  It's not an
important topic, usually,


        Stefan