[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Obsoleting more progressively

From: Andreas Röhler
Subject: Re: Obsoleting more progressively
Date: Wed, 03 Nov 2010 08:59:51 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/20100711 Thunderbird/3.0.6

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?


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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]