Based upon definitions I have read of the term deprecation, I get a general sense that deprecation is usually reserved for moving on to other methods/classes for good for reasons such as (and I borrow from Wikipedia):
- The feature has been replaced by a more powerful alternative feature.
- The feature contains a design flaw—frequently a security flaw—and so should be avoided, but existing code depends upon it.
- The feature is considered extraneous, and will be removed in the future in order to simplify the system as a whole.
- A future version of the software will make major structural changes, making it impossible (or impractical) to support older features.
- Standardization or increased consistency in naming.
- A feature that once was only available independently is now combined with its co-feature.
Is it proper to deprecate a method/class if there is a possibility that future decisions made in later versions of the code might require reinstatement of the deprecated functionality? That is, is it proper to undeprecate? Perhaps if not, what is the correct way to deal with this section of code?
In the context I am talking about, the deliverable is really a subsystem which is included in other projects. Therefore, the possible exposure is between development teams. However, some of the deprecated classes for instance would not be classes that would normally be directly instantiated by other projects. They could, but it generally does not fit into their use cases. An example that comes to mind is Stanford CoreNLP where just because a class or a method is accessible does not mean it is something that you should be using.
