# Section 6.2:
Class Definitions

Each individual class forming part of a Sather program has a place in a (non-recursive) type graph which is specific to that individual program; either as an abstraction or an implementation class. This document enhances the previous specification of Sather 1.1 by introducing the notion of a library name-space (see Section 6.5 for the type graph and type compatibility rules).

All classes in a program are either in the global class name-space or in an individual library name-space. The pervasive classes and those classes in the Required Library are in the global class name-space.

NOTE | Sather provides a code inclusion facility through the use of partial clases (which may not themselves be instantiated). The form of definition of a partial class is identical to that of any other implementation class except for the initial keyword partial. Details of its definition and usage are covered in Section 6.2.2 and 6.6.6 respectively.

#### Concrete Syntax

The two production rules below specify the overall form of a class specification as identified in the source text rule of Section 6.1. Note that the identifier forming part of the library signifier must not appear as a class name in the global name space or as a library name in that name space.

class specification = | [library signifier],
| (abstract class definition | class) ;

library signifier = | Library_SY, identifier ;

#### Abstract Syntax

Each class is either a dependent class as defined in Section 6.1 or it is the program class. From the point of view of this section of the Abstract Syntax an individual class is defined by the following formal definitions -

types
Accesses = token
inv acc ==
(acc = Read)
or (acc = Write)
or (acc = Use)
or (acc = Once) ;
Visibility = set of Accesses ;

NOTE | The Visibility type describes the accesses which may be made to an individual feature or argument. If a feature is private then the set will be empty!

Class_Kind = token
inv class ==
(kind = External)
or (kind = Abstract)
or (kind = Immutable)
or (kind = Reference) ;
Method_Kind = token
inv times ==
(times = One_Shot)
or (times = Multiple) ;
Feature ::
name : token
args : [ set of Feature ]
kind : [ Type_Specifier ]
value : [ Expression ]
impl : [ seq of Statement ]
vis : [ Visibility ]
ext_vis : Visibility
uses : [ Method_Kind ] ;
Class_Def ::
kind : Class_Kind
features : set of Feature
typenode : [ Type_Graph ]

#### Static Semantics

The well-formedness of a class depends on which kind of class it is. The function following thus depends on the kind as given in the cases clause.

wf_class : Class_Def -> bool
wf_class(mk_Class_Def(kind,comps,graph)) ==
cases kind:
wf_abstract_class(mk_Class_Def(kind,comps,graph))
<Reference> -> wf_reference_class(mk_Class_Def(kind,comps,graph))
<Immutable> -> wf_immutable_class(mk_Class_Def(kind,comps,graph))
<External> -> wf_external_class(mk_Class_Def(kind,comps,graph))
end

#### Dynamic Semantics

Since individual classes are made up of sets of feature, the meaning of a class is the meaning of those features as invoked during execution of a program in some sequence of feature executions for that particular program execution. Abstract classes have no dynamic meaning since they are provided as a skeleton on which a class structure is built by the implementation.

A class component of the specification, therefore, has no dynamic semantics associated with it. It is merely a static specification of a set of features which themselves have individual dynamic semantic meaning during program execution - providing, of course, that they occur in the sequence of feature executions.

| Specification Index |  | Language Index |  | Section 6 Index

Comments or enquiries should be made to Keith Hopper. Page last modified: Wednesday, 25 October 2000. |