Re: [patch] Deprecate XM_FILE and TM_FILE

[Andrew Cagney <cagney@gnu.org>]

>>> 1) When do you consider that an alternative mechanism exists?
> 
> 
> When it is there in the sources, of course.
> 
> 
>>>    It will take same work to get
>>>    things autoconfiscated, and using alternative mechanisms for other
>>>    deprecated things will require even more work.  Where do we draw
>>>    the line?
> 
> 
> We draw the line by deprecating things only when they are replaced by
> the better mechanism.  This could be done by the same patch that
> deprecates the old mechanism.

Eli you previously wrote:

 > a feature that is being actively used cannot be deprecated.

I think this debate is over the point at which something can be deprecated.

That Java URL gives the motivation as:
>     The need for deprecation comes about because as a class evolves, its API changes. Methods are renamed for consistency. New and better methods are added. Attributes change. But making such changes introduces a problem: You need to keep the old API around until people make the transition to the new one, but you don't want developers to continue programming to the old API.

For GDB, as soon as we've got the new mechanism up and running - 
confirming its ok - we're going to draw a line and deprecate the old 
mechanisms.  We're not going to require that every single detail of 
every single dependant variant also be addressed.

>>> 2) We need a way to stop people from using constructs that we are
>>>    phasing out.
> 
> 
> We can easily do that (and actually do that) by rejecting patches that
> use the old mechanism.

We don't.

Developers commit changes using old mechanisms right up until the day it 
has been explicitly deprecated.  In the past, requests to not use old 
mechanisms have been [er] declined, the rationale being that the 
mechanism has to first be clearly, explicitly and formally deprecated 
(as is being done with this e-mail).

Consequently, we deprecate explicitly and early.

>>>    People tend to copy code from existing ports.  In doing so they
>>>    also copy things that we want to get rid of.  As a result it takes
>>>    more time to review the associated changes.  It might also
>>>    discourage contributors if we tell them that they shouldn't use
>>>    those features: "Why didn't you tell me that before?".
> 
> 
> If that is the problem, we could have the list of features not to be
> used spelled out somewhere.  This somewhere doesn't have to be in the
> sources.

Such as:

> GDB's host configuration support normally happens via Autoconf. New host-specific definitions should not be needed. Older hosts GDB still use the host-specific definitions and files listed below, but these mostly exist for historical reasons, and will eventually disappear.

As Mark noted, the unfortunate reality is that people program by 
cut/paste.  We put these markers where people have the greatest 
likelyhood of seeing them.

This problem isn't something unique to GDB.

>>>    From time to time I tend to do a "grep -i
>>>    deprecated" on the source files associated with the stuff I care
>>>    about and fix things.  The fact that prepending deprecated_ to
>>>    things tends to make the code look so ugly helps in that respect.
> 
> 
> We could have the ari script do that for us.  It could use a list of
> old mechanisms mentioned above.

The ARI does, see "deprecate" and "obsolete".  However, they are both 
strictly advisory.  People wanting to future proof their code are 
strongly encouraged to avoid those mechanisms.

Andrew