The Invariant Table

The SCOOP compiler creates a specific hash table data structure called the “invariant table” for each stated object. The invariant table is created along with the symbol table. One of its main uses is to hold the bindings between typestates and their invariants. Each typestate name of a stated object is an entry in the invariant table in the same way that each variable or object name is an entry in the symbol table. Each row in the invariant table holds the typestate name, its typestate invariant, its binding rule, and a flag to mark whether the binding rule is true or false. If the flag for a specific typestate is true then that specific typestate is the current typestate of the object. The stated type system, at any point in time, evaluates the binding rule and sets the flag accordingly for any given typestate name entry in the invariant table.

The invariant table always holds two default typestate names for each stated object, i.e. the

null and undefined typestates. As previously mentioned, whenever a stated object points to a null reference then it is in the null typestate. Whenever there is no typestate binding rule that evaluates to be true for a stated object then the object is transitioned to the undefined

typestate.

The stated type system always points to a typestate name in the invariant table corresponding to the current typestate of a stated object. In other words, for each stated object, the stated type system always points to that typestate entry in the invariant table which has its flag set to true. If the binding rule of the current typestate is evaluated as false, then a recovery operation is performed by the SCOOP compiler that either transitions the typestate of the

81

object to the typestate for which the binding rule is true in the invariant table, or transitions the object to the default undefined typestate. The default undefined typestate is mentioned in Section 5.5.

Table 6.1 illustrates an invariant table for the iterator stated object, given in Figure 6.1, while it is in the traversal typestate.

Typestate Invariant Invariant rule Valid

null This this == null False

error This this ≠ null AND this.curr_tstate ∉ Titerator False

initial j,i,

htbuckc j== -1 AND i < htbuckc False

traversal j, i,

htbuckc j==0 AND i < htbuckc True

end j, i,

htbuckc i== htbuckc False

Table 6.1

6.6 Typestate Extension

In this section we illustrate typestate extension with a few variations in our code fragments. The sample code in Figure 6.2 is a SCOOP program. It includes a File class with an openfile typestate, closefile typestate and eof as an extension of the openfile typestate.

[state(openfile,closefile,eof)] class File{

string name;

[openfile]{

public read()[openfile | eof]{..}

} [eof]:[openfile]{ ………… } [closefile]{ ……… } }

82

The sample code in Figure 6.3 is the SCOOP generated translation of the code given in Figure 6.2.

class File{ enum state {openfile, closefile,eof} string name;

state curr_st;

class openfile{ // openfile ‘state class’

public read() [openfile | eof]{...}

}

class eof:openfile{…… // eof ‘state class’ …..

}

class closefile{ // closefile ‘state class’ ………….

} }

Figure 6.3 SCOOP-generated File Stated Class

The sample code in Figure 6.4 is a SCOOP program. It includes a File class and an

Imagefile as its subclass. The File class has an openfile typestate, a closefile

typestate and an eof typestate as an extension of the openfile typestate. The Imagefile overrides the openfile, closefile and eof typestates of the parent class File.

83 [state(openfile,closefile,eof)] class File{

string name;

[openfile]{

public read()[openfile | eof]{...

} } [eof]:[openfile]{ ………… } [closefile]{ ……… } } class Imagefile:File{ ... [openfile]{ .... } [closefile]{ ... } [eof]:[openfile]{ ………… } } }

Figure 6.4 SCOOP File and Imagefile Stated Class

The sample code in Figure 6.5 is the SCOOP generated translation of the code given in Figure 6.4.

84

class File{ enum state {openfile, closefile, eof} string name;

state curr_st;

class openfile{ //openfile ‘state class’

public read() [openfile | eof]{...

} }

class eof:openfile{…… // eof ‘state class’ …..

}

class closefile{ //closefile ‘state class’ ………….

} }

class Imagefile:File{

enum state {openfile, closefile, eof}

class openfile{ //openfile ‘state class’

public read() [openfile | eof]{...

} }

class eof:openfile{…… // eof ‘state class’ …..

}

class closefile{ // closefile ‘state class’ ………….

} }

Figure 6.5 SCOOP-generated File and Imagefile Stated Class

The sample code in Figure 6.6 is a SCOOP program. It includes a File class and an

Imagefile as its subclass. The File class has the openfile and closefile typestates. The programmer in the Imagefile subclass overrides the openfile typestate and then extends the openfile typestate by the eof typestate.

85 [state(openfile,closefile,eof)] class File{ string name; [openfile]{ public read()[openfile]{... } } [closefile]{ ……… } } class Imagefile:File{ ... [openfile]{ .... } [closefile]{ ... } [eof]:[openfile]{ ………… } } }

Figure 6.6 SCOOP File and Imagefile Stated Class With Typestate Extension

The sample code in Figure 6.7 is the SCOOP generated translation of the code given in Figure 6.6.

86 class File{ enum state {openfile, closefile, eof} string name;

state curr_st;

class openfile{ // openfile ‘state class’

public read() [openfile | eof]{...

} }

class closefile{ // closefile ‘state class’ ………….

} }

class Imagefile:File{

enum state {openfile, closefile, eof}

class openfile{ // openfile ‘state class’

public read() [openfile | eof]{...

} }

class eof:openfile{…… // eof ‘state class’ …..

}

class closefile{ // closefile ‘state class’ ………….

} }

Figure 6.7 SCOOP-generated File and Imagefile Stated Class With Typestate Extension

6.7 Typestate Invariants With Typestate Extension and