This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Deprecate XM_FILE and TM_FILE



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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]