# Section 6.2.2:
Implementation Class Definitions

An implementation class contains features which implement some of the functionality of tha associated abstract data types. In practice, it is common to find that 'creation' features of a class are not part of any super-type abstractions. Where a type is not related to any other type it is again not essential to define an abstraction for this as there is only one implementation.

All forms of implementation class are syntactically similar with the one exception - an external class may contain merely the signatures which bind to external resources.

#### Concrete Syntax

Partial classes which do contain implementation source text are not formal classes in the sense that they may not be instantiated. They are a concrete syntax feature of the language only. Where a partial class is included then (with parameter substitution if necessary) it forms part of the text of the including class. For this reason the existence of the partial class is merely at the source text level (possibly using macro-style substitution for generic arguments when present. It does not form a separate program component.

See additionally the stub mechanism which is provided, again at the concrete syntax level, to enable 'forward' definitions to be given which require a suitable implementation in the including class.

class = | [class type], Class_SY, concrete type name, [generic arguments],
| [subtyping clause], Is_SY,
| [class element], {Semicolon_SY, [class element]}, End_SY ;

class type = Immutable_SY | Partial_SY | (External_SY, [identifier]) ;

generic arguments = | Left_Brace_SY, parameter declaration,
| {Comma_SY, parameter declaration}, Right_Brace_SY ;

subtyping clause = Left_Angle_Bracket_SY, type specifier list ;

supertyping clause = Right_Angle_Bracket_SY, type specifier list ;

parameter declaration = | type name, [Left_Angle_Bracket_SY, type specifier] ;

#### Abstract Syntax

Corresponding to the above concrete syntax there are three corresponding abstract forms of a Class_Def - with different kind and different invariants. The kind component is used when evaluating the dynamic semantics of a class instantiation feature.

Ref_Class_Def ::
kind : Class_Kind
features : set of Feature
typenode : [ Type_Graph ]
inv mk_Class_Def(kind,ftrs,_) ==
(kind = Reference)
and (forall feat in ftrs &
((feat.impl <> nil)
or (feat.value <> nil)
Immutable_Class_Def ::
kind : Class_Kind
features : set of Feature
typenode : [ Type_Graph ]
inv mk_Class_Def(kind,ftrs,_) ==
(kind = Immutable)
and (forall feat in ftrs &
((feat.impl <> nil)
or (feat.value <> nil)</pspan>
Ext_Class_Def ::
kind : Class_Kind
features : set of Feature
typenode : [ Type_Graph ]
inv mk_Class_Def(kind,ftrs,_) ==
(kind = External)

#### Static Semantics

The well-formedness criteria for the first two implementation class kinds is, at this level, identical. However, at the class element and below the kind component needs to be taken into account for well-formedness checking. This relates to the different role played by an immutable and a reference class.

wf_reference_class : Class_Def -> bool
wf_reference_class(mk_Class_Def(kind,comps,graph)) ==
forall feat in set comps &
wf_class_element(feat,kind)
and forall feat1, feat2 in set comps &
feat1 <> feat2 => is_disjoint_sig(feat1,feat2)
and wf_type_graph(graph) ;
wf_immutable_class : Class_Def -> bool
wf_immutable_class(mk_Class_Def(_,comps,graph)) ==
forall feat in set comps &
wf_class_element(feat,kind)
and forall feat1, feat2 in set comps &
feat1 <> feat2 => is_disjoint_sig(feat1,feat2)
and wf_type_graph(graph) ;

For an external class the criteria for well-formedness are different since an external class may define a Sather interface to some environment feature which the program wishes to make use of.

wf_external_class : Class_Def -> bool
wf_external_class(mk_Class_Def(_,comps,graph)) ==
forall feat in set comps &
(wf_external_signature(feat)
or wf_class_element(feat,kind)
and forall feat1, feat2 in set comps &
feat1 <> feat2 => is_disjoint_sig(feat1,feat2)
and wf_type_graph(graph) ;

NOTE | The well-formedness function wf_external_signature is essentially implementation-defined by virtue of the differing external environments on various computer platforms. It should be compatible with wf_abstract_signature but may make restrictions on the kind of arguments or return values from such external features.

#### Dynamic Semantics

TO BE DONE

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

Comments or enquiries should be made to Keith Hopper . Page last modified: Sunday, 28 May 2000. |