Sather Home Page

Section 6.2.2:
Implementation Class Definitions

An implementation class contains features which implement all of the functionality of the abstract data types from which it inherits; it may also implement additional features. In practice, it is common to find that 'creation' features of a class are not part of any super-type abstractions. Where a particular type is not related to any other type either by direct inheritance or otherwise it is not essential that an abstraction for this be defined since 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)

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 -

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: Wednesday, 25 October 2000.
Produced with Amaya