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] |
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.
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.
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.
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.
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.
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |