BASIC LANGUAGE CONCEPTS

TYPEDEF StudentT {

STRUCTURE { NATURAL studentid ; }

}

TYPEDEF AcademicT {

STRUCTURE { NULLABLE < STRING > spec ialisation ; } } TYPEDEF DateT { } STRUCTURE { } NULLABLE < YearT > NULLABLE < MonthT > NULLABLE < DayT > TYPEDEF Proj e ctT { STRUCTURE { NATURAL STRING year ; month; day ; proj ectld ; t itle ; DateT begin ;

NULLABLE < DateT > end ;

} } TYPEDEF TimeT { STRUCTURE { } }

NULLABLE < NATURAL > hour ; NULLABLE < NATURAL > minute

TYPEDEF LectureTimeT { STRUCTURE { WeekDayT weekDay ; } } TimeT start ;

NULLABLE < TimeT > end ;

TYPEDEF LectureT {

STRUCTURE { NULLABLE < LectureTimeT > t ime ; }

}

TYPEDEF EnrolmentT {

STRUCTURE { NULLABLE < DateT > date ; } }

TYPEDEF RecordT {

STRUCTURE { NULLABLE < GradesT > result ; }

}

Markus Kirchberg

4.2. B ASIC LANG UAGE CONCEPTS _{Markus Kirchberg}

4.2.5 Classes and Objects

Types are used to represent simple concepts, such as structures with few members whose values are mutable. Classes, on the other hand, are meant to be used to group larger (i.e. more complex) structures or real-world objects. The structure of a class of objects is defined over existing types, unnamed types (i.e. types without a behaviour that are defined in the class structure itself) and existing classes (either as specialisation, i.e. !sA-relationships / inheritance, or as reference) . Each object is uniquely identified by a hidden, globally unique object identifier (of a hidden, internal type __ D ID) . We will now start to consider how classes are specified.

Structure of a Class. Classes can be seen as templates for creating objects. They specify the features that all objects of a class have in common. These features (also referred to as class members) include named constants, variables, methods, and simple constraints. Syntax Snapshot 4.5 outlines the relevant portion of the iDBPQL syntax. Syntax Snapshot 4.5 {iDBPQL Class Definitions)

ClassDef init ion ClassModi f ierDecl , " CLASSDEF" , Id ,

[ ' < ' , ClassParameter-List , ' > ' ] , [ " ! sA" , Classld-List ] , [ "WITH " , ' { ' , { ( ClassParaConstrClause I PrecedenceClause I RenamingExpr ) , ' ; ' } , ' } ' ] , ' { ' ' [ StructuredType ] , [ " BEHAVIOUR" , ' { ' , { MethodSignature } , ' } ' ] , [ ConstraintDeclarat ion ] , ' } ' ;

11 t yp i ca l ly, the s t ructured typ e is not ass igned a uni que i dent ifier. In this cas e , 1 1 w e imp l i c i t ly ass o c i a t e the i d e n t ifier o f t h e c l ass a l s o wi th the s t ruc tured

11 t yp e . This is l a t er used when t yp i ng query express ions .

ClassParaConstrClause = ClassParameter , " IsA" , Classid-List ; PrecedenceClause ( Id , " IS ACCEPTED FROM " , Id ) I

( Id , " COMBINES " , I d , { " AND" , Id } ) ;

VariableDecl VarModif ierDecl , Type , Id , [ "REVERSE" , Id ] ;

11 ext ended vers i on

MethodSignature MethodModif ierDecl , I d , ' ( ' , [ Parameter-List ] , ' ) ' , ResultType ;

ConstraintDeclarat ion = " CONSTRAI NT " , [ Id ] , ' { ' { DomainConstraint Ent ityConstraint } , ' } ' ;

DomainConstraint CheckConstraintDecl I NotNullConstraintDecl ; EntityConstraint UniqueConstraintDecl ;

CheckConstraintDecl " CHECK " , ' ( ' , Expression , ' ) ' ;

NotNullConstraintDecl = " NOT NULL " , ' ( ' , Id-List , ' ) ' ;

UniqueConstraintDecl

ClassModifierDecl MethodModif ierDecl

" UNIQUE " , ' ( ' , Id-List , ' ) ' ;

[ ScopeModif ierDecl ] , [ StaticModif ierDecl ] , [ ClassCatModif ierDecl ] , [ FinalModif ierDecl ] ; [ ScopeModif ierDecl ] , [ StaticModif ierDecl ] , [ AbstractModif ierDecl I FinalModif ierDecl ] ;

4 . 2 . B ASIC LANG UAGE CONCEPTS _{Markus Kirchberg}

VarModif ierDecl [ ScopeModif ierDecl ] , [ StaticModif ierDecl ] ;

Stat icModif ierDec l " STATI C " ;

ClassCatModif ierDecl = AbstractModifierDecl I "COLLECTION" I " CONCRETE" ;

AbstractModif ierDecl " ABSTRACT" ;

F inalModif ierDec l = " FINAL " ;

0

The CLASSDEF keyword is used to specify classes. While modern object-oriented programming languages strictly enforce the encapsulation property (and, thus, hide all structural properties of classes and their corresponding objects) , classes in iDBPQL are not used primarily as information hiding mechanism. In a higher-level version of iDBPQL, concepts such as class interfaces and module interfaces may take over this part as briefly indicated in Section 3.2. While access modifiers such as PRIVATE and PUBLIC are supported, classes are meant to expose structural properties. In fact, the PUBLIC access modifier is the default for all class definitions and class members. Thus, all public properties of a class are accessible wherever the respective class is accessible. The PRIVATE scope modifier restricts member visibility. However, in contrast to conventional OOPLs, PRIVATE does not limit the view to the class. Instead, it only limits the view to the class where the member is declared and all its sub-classes (i.e. private and public properties are inherited) . This is in line with the 'No Paranoia Rule' as advocated in [132] and also similarly adopted in the object-oriented programming language Theta [82] that is designed for the object base Thor [83] . Having a reduced information hiding mechanism at the class-level but a strong information hiding mechanism at the module­ level allows for more efficient implementations of closely related parts within a module. In particular, this strategy is advantageous when object-orientation is only taken to medium granularity6 - as iDBPQL does. It should be noted that iDBPQL does not fully adhere to the ' No Paranoia Rule'. Private properties of classes are hidden within the respective class/sub-class hierarchy. This addresses the criticism of the ' No Paranoia Rule ' that it is too open, especially for large modules.

Let us consider some initial examples:

EXAMPLE 4 . 9 . We will define classes based on type definitions for the university ap­

plication as outlined in Example 4.8. First, the PersonC class is defined. It is based on the previously defined PersonT value-type as follows:

01 CLASSDEF PersonC {

02 STRUCTURE { PersonT ; }

03 }

Alternatively, we could specify the same class without reusing the existing value-type PersonT (i.e. the PersonC class is defined over an unnamed structure type) :

10 CLASSDEF PersonC {

1 1 STRUCTURE {

12 NATURAL personid ;

6 Medium granularity of object-orientation means that there is a distinction between objects and values. Objects correspond to larger abstractions such as real-world objects, whereas values represent Integer values, or simply structured values.

4 . 2 . BASIC LANG UAGE CONCEPTS

13 NameT name ;

14 NULLABLE < AddressT > addr ; 15 _}

16 }

Markus Kirchberg

However, the underlying unnamed type is identical to the PersonT value-type. Thus,

both class definitions are identical. D

All structural class members considered so far are associated with class instances, i.e. they define the state of objects. We refer to such structural class members as

instance variables . In addition, classes may also contain class variables . There exists only one copy of a class variable that serves all objects of the class, not one per object as for instance variables. Per default, variables are instance variables. Class variables must be declared explicitly using the STATIC keyword.

While classes are regarded as templates for creating objects, objects themselves are considered instances of classes . They are created using the NEW keyword followed by the name of the class that the object will be based upon. Object creation results in a reference to the object being returned (not the actual object) . In iDBPQL, objects are never accessed or returned directly. Object access is possible only through references or class-collections that are introduced further below. Each object has an associated value7 that identifies the object. The type of a (reference-)value is reference-ta-x where x is the class of the object. Such types are referred to as reference-types or object-types

(Figure 4 . 1 on page 71 details all iDBPQL types including reference-types) . In contrast to value-types, all reference-types have a common, unique default value, which is the NULL reference (of type reference-to-nothing) . The NULL value does not denote an object rather its absence.

Variables and Reference-Types. In Section 4.2.4 three types of variables have already been introduced. Above, instance variables and class variables have been added. Having introduced reference-types, the concept of a variable has to be extended to cover such types. Syntax Snapshot 4.5 details an extended means of declaring variables. Variables of a primitive type still contain a value of the specified type. In contrast, variables of a reference-type contain either the NULL value or a value that references an instance of the specified class or an instance of a sub-class of the specified class.

Variables of a reference-type may have a corresponding reverse variable. Per default, all variables are unidirectional (i.e. no such reverse variable exists) . However, variables of a reference-type may be bidirectional. Thus, a corresponding reverse variable exists. A reverse variable is of reference-type reference-ta-x where x is the class in which the bidirectional variable is defined in or a collection over reference-ta-x . A bidirectional variable must be declared in both classes that refer to one another. Each of the two declarations must contain the REVERSE keyword followed by the name of the corresponding reverse variable. While unidirectional variables of a reference-type can only represent one-to-one and one-to-many associations between classes, bidirectional variables can represent one-to-one, one-to-many and many-to-many associations.

4 . 2. BASIC LANGUAGE CONCEPTS _{Markus Kirchberg}

Before considering an example consisting of such associations, it has to be noted that definitions of the structured type, type parameters and the built-in type constructors (all introduced in Section 4 .2.4) are extended to support variables of both value-types and reference-types.

EXAMPLE 4 . 1 0 . Again , let us consider the university application. A class representing departments may be defined as follows:

0 1 CLASSDEF DepartmentC { 02 STRUCTURE { 03 04 05 06 07 08 } 09 } DepartmentT ; PersonC SET < StudentC > SET < StudentC > SET < AcademicCcc director ;

maj orStudents REVERSE maj or ; minorStudents REVERSE minor ;

> staff REVERSE staffMemberOf ;

11 exis t i ng typ e defini t ion 11 uni d i r e c t i ona L reference 11 b i d i r e c t i ona L reference 11 b i d i r e c t i ona L reference 11 b i di re c t i onaL reference

This class definition contains members resembling both unidirectional and bidirectional references. By default, such references are initialised to refer to the NULL value. D Methods. Besides structural properties, classes contain methods. A method corre­ sponds to a block of iDBPQL statements, i.e. an evaluation plan. As outlined in Syn­ tax Snapshot 4.5, methods are declared by specifying method modifiers, the method name, any method parameters (surrounded by parentheses) , a colon, and the result type. Method names need not to be unique, however, the method name together with its method parameters (in number or types) must be.

iDBPQL classes may contain four types of methods. These are:

- Instance methods , which are associated with class instances, i.e. objects. Such meth­ ods rely on the state of the specific object instance, i.e. the behaviour that the method invokes relies upon its instance's state. Per default, methods are instance methods.

- Class methods (also referred to as static methods) , which are associated with classes and not their instances. Such methods do not access instance variables of any object of the class they are defined in. They only access static members. Most commonly they take all their data only from method parameters and perform computations from those parameters, with no reference to instance variables.

Class methods must be declared explicitly using the STATIC keyword.

- Object constructors , which are special instance methods (with no result type) that are called automatically upon the creation of an instance of a class. Once invoked, object constructors initialise instance variables (in fact, instance variables inherited from base-classes as well as instance variables defined in this class) . Similar to other PLs (e.g. Java, C++ and C#) , object constructors are distinguished from instance methods by having the same name as the class they are associated with.

The object constructor with an empty argument list must always exist. If not speci­ fied explicitly, it is generated automatically. A system-generated default constructor is specified as foll-ows:

4.2. BASIC LANGUAGE CONCEPTS _{Markus Kirchberg}

0 1 EVALPLAN myNewClassC ( VOID ) {

02 SUPER ( ) ; // resp e c t ive invoca t i on s eman t i cs are out L ined

03 // L a t er in Examp L e 4 . 21

04 RETURN ( VOID ) ;