Operators on Class Expression

In RSL, there are three ways of manipulating a class expression:

1. Extension.

2. Hiding.

3. Renaming.

Common for these three operators are that they all result in a new class expression, which may be manipulated further.

Extension

The idea of extension in RSL is to build a class expression in successive steps, adding new properties at each step. The form of an extending class expression is:

extend base class with extending class

The extending class expression may use all the declarations defined in the base class expression. In fact, the extending class expression is equivalent to a basic class expression containing all the declarations of bothbase class and extending class. Bothbase classandextending classmay be any kind

of class expression including an identifier of another scheme, this is called a scheme instantiation. The most common use of an extending class expression is to let the base class be an identifier of a scheme defined elsewhere, and let extending class be a basic class expression containing declarations of the new properties.

The way the extension is defined in RSL gives two possibilities for trans-lation into Java:

1. Use the fact that an extending class expression in RSL is equivalent to a basic class expression, and translate the basic class expression 2. Use the possibility in Java to extend one class with another.

Both of these suggestions have advantages and disadvantages. The disad-vantage of the first suggestion is, that the Java source code generated is not divided into several classes. It is harder to read and not as close to the idea in the specification, which is to have the system divided into several smaller units. The advantage of the first suggestion is that it is easy to deal with since all that is needed is a translation of all the declarations of the two class expressions. The advantage of the second suggestion is that the idea of the specification to split the details of the specification into smaller units is preserved. This property is kept by creating one class in Java per class expression in RSL, and let the classes created extend each other in the right order, as shown in Example 2.4. The disadvantage of the second suggestion is that it is more complicated to deal with than one large basic class expression.

The second suggestion is chosen because it preserves the idea of dividing a specification into several schemes, and keeping this as several pieces in Java.

Hiding

The purpose of the hide operator in RSL is to hide identifiers used inside a class expression from modules using the class expression either by extension or by instantiation. The form of a hiding class expression is:

hide idin class expression

In Java, identifiers must be declared public to be accessible from classes in other packages. In RSL, all declarations are accessible by other modules un-less they are explicitly hidden, therefore, as default all fields and methods are declaredpublic in the Java source code generated. When the hide expression is used the access modifier of a field or method is changed to protected to disallow access, as shown in Examples 2.5 and 2.6. As stated later type defi-nitions should be translated as classes in Java. These classes are by default

Example 2.4 Using the extend feature in Java for extension in RSL.

schemeLIST STATE = class

variable list : Int^∗ end

schemeLIST OPERATIONS = extend LIST STATE with class

value

is empty : Unit → read list Bool is empty() ≡ list =hi

end

public c l a s s LIST STATE {

public s t a t i c RSLListDefault<I n t e g e r> l i s t ; // R S L L i s t D e f a u l t i s e x p l a i n e d i n S e c t i o n 2.3.2 . }

public c l a s s LIST OPERATIONS extends LIST STATE { public s t a t i c boolean i s e m p t y ( ) {

return l i s t . e q u a l s (new RSLListDefault<I n t e g e r>() ) ; }

}

declared public and put into a file of their own. If a type is to be hidden, the corresponding class should be declared private. A private class must be declared within the class that uses it. This presents a problem because in a specification more than one type definition may use a hidden type definition as a type of a component. When these type definitions are translated as dif-ferentpublic classes in different files, then there is no place where theprivate class corresponding to the hidden type can be declared so that both public classes can access it. Hiding of types should therefore be disallowed in the translation.

Example 2.5 Translation of a scheme not hiding the variable.

schemeLIST = class

variable list : Int^∗ end

public c l a s s LIST {

public s t a t i c RSLListDefault<I n t e g e r> l i s t ; }

Example 2.6 Translation of a scheme hiding the variable.

schemeENCAPSULATED LIST = hide list in

class

variable list : Int^∗ end

public c l a s s ENCAPSULATED LIST {

protected s t a t i c RSLListDefault<I n t e g e r> l i s t ; }

Renaming

The purpose of the renaming in RSL is to rename an identifier in relation to other modules. The form of a renaming class expression is:

use id1 for id2, . . . , idm for idn in class expression

In Java, there is no concept of renaming identifiers, therefore the renaming must be done before the specification is translated. In RSL a renaming class expression can be expanded into a basic class expression simply by renaming all the identifiers in the class expression according to the list of renaming pairs as shown in Example 2.7. In the translation into Java this expansion should be used.

Example 2.7 Renaming class expression.

schemeSTACK SCHEME = use stack for list in

LIST STATE Is equivalent to:

schemeSTACK SCHEME = class

variable stack : Int^∗ end