Re: [patch] Deprecate XM_FILE and TM_FILE

[Andrew Cagney <cagney at gnu dot org>]

> > > Now if I were to try to either:
> > >
> > > - deprecate or delete GDBINIT_FILENAME without a replacement
> > > - delete XM_FILE without eliminating DJGPP's dependence
> > >
> > > then you'd have strong grounds for complaint.
>
>
> Deprecating XM_FILE means it will be deleted in the next major
> release.  So I'm complaining now to prevent the more-or-less automatic
> deletion of anything that matches the regexp "deprecated.*"
> (case-insensitively) in the near future, when it would be too late to
> complain.

This isn't correct.

Deprecating something does not mean that it will automatically be 
deleted in the next major release.  We've still got stuff that was 
deprecated in '99!

> > > I think you're asking who will cut the code necessary to acheive
> > > each of:
> > >
> > > - eliminate/replace GDBINIT_FILENAME from xm-*.h
> > > - eliminate/replace CRLF_SOURCE_FILES from xm-*.h
> > > - eliminate/replace DIRNAME_SEPARATOR from xm-*.h
>
>
> Yes.  And I also request that the replacement for these xm-*.h
> definitions be in place _before_ we deprecate XM_FILE, because in my
> book, a feature that is being actively used cannot be deprecated.

Java defines deprecation as:
http://java.sun.com/docs/books/tutorial/post1.0/converting/deprecation.html
> What Does Deprecation Mean?
>
>     You might have heard of the term "self-deprecating humor." It describes humor that minimizes one's own importance.
>
>     Similarly, when a class or method is deprecated, it means that the class or method is no longer considered important. It is so unimportant, in fact, that it should no longer be used at all, as it might well cease to exist in the future.
>
>     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.
>
>     The ability to mark a class or method as "deprecated" solves the problem. Existing classes that use the old API continue to work, but the compiler can issue a warning when it finds references to deprecated items. Meanwhile, API documentation can warn the user against using the deprecated item and tell the user how to avoid doing so. To mark API as deprecated, the implementer of the API uses a special tag in doc comments: @deprecated.

The task of formally deprecating a mechanism, and the task of 
eliminating uses are separate, we need to keep them as such.

How about we get this in, and then I'll follow up (by 6.3) with patches 
to finish this (as I said, I suspect I'll be doing the dirty work).

Andrew