I'm currently writing a design to add the possibility to mark a field or attribute for an entity as read-only in preparation for imminent removal. The idea is that, once the field has been thus marked and the change has propagated everywhere in production, we can run a job against our database to remove that field from the data permanently.

What is the best descriptive short term for this state? Currently, we're thinking of calling such fields "deprecated". To me, however, this often just means "strongly discouraged" - you're not supposed to use it, but you might end up doing so anyway (vid. the Java @Deprecated annotation). Is there a stronger term for this that implies that the field will in fact never be written to again? I've thought of moribund and defunct so far.

  • 3
    I don't see anything wrong with deprecated. – Dan Wilson Oct 10 at 18:54
  • "Double secret deprecated"? :-) – user949300 Oct 10 at 19:06
up vote 0 down vote accepted

'Deprecated' works; 'obsolete' is another option:

no longer in use or no longer useful

This is how it's called in the C# / .NET world.

But the most important thing is not how you call it, but that you communicate to the users (developers) of your data model / API what is going to happen and what they should do/use instead. Most languages offer a feature for this, e.g. for Java the @deprecated javadoc tag:

/**
 * @deprecated  As of release 1.3, replaced by {@link #getPreferredSize()}
 */
@Deprecated public Dimension preferredSize() {
return getPreferredSize();
}

and for C# the Message property of the ObsoleteAttribute:

[Obsolete("Method1 is deprecated, please use Method2 instead.")]
public void Method1()
{ … }

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.