![]() |
Section 6.2:
|
![]() |
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 classes (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. |
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.
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 ]
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: <Abstract> -> 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
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: Thursday, 26 April 2001. |
![]() |