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, 2018 at 18:54
  • "Double secret deprecated"? :-)
    – user949300
    Oct 10, 2018 at 19:06

1 Answer 1


'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 agree to our terms of service, privacy policy and cookie policy

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