This state information is used to determine at compile-time which operations are valid to be invoked upon an instance of the type.
The name "typestate" stems from the fact that this kind of analysis often models each type of object as a finite-state machine.
[1] Typestate analysis was introduced by Rob Strom in 1983[2] in the Network Implementation Language (NIL) developed at IBM's Watson Lab.
In recent years, various studies have developed ways of applying the typestate concept to object-oriented languages.
Strom and Yemini give a linear-time algorithm that checks a given program text for typestate-consistency, and computes where to insert which coercion operation, if any.
In order to achieve a precise and effective typestate analysis, it is necessary to address the problem of aliasing.
As another issue, for some programs, the method of taking the greatest lower bound at converging execution paths and adding corresponding down-coercion operations appears to be inadequate.
Two examples are the Plaid and Obsidian languages, which are being developed by Jonathan Aldrich's group at Carnegie Mellon University.
struct{int x;int y;int z;}
.