 |
Section 6.6.6:
Include Clause
|
 |
Code inclusion in Sather is completely independent of class behaviour
inheritance (sub-typing and/or super-typing). It is a mechanism by which an
implementation class (or partial class) may
- Make use of code written in other implementation (or partial) classes
syntactically. Where the included class has generic arguments these are
substituted by the arguments provided in the inclusion specification as a
form of macro expansion.
- Make use of a non-global class library.
Concrete Syntax
The inclusion facility provided in accordance with this concrete syntax,
whether of a non-global library or some partial class, is primarily concerned
with modification of name-space visibility and name substitution. The results
of this may be seen as source text transformation and, therefore, have no
separate corresponding abstract syntax, static or dynamic semantics. There are
instead four different required concrete syntax manipulations :-
- Making names visible
- In the case of class inclusion (whether of a partial class or of any
other non-abstract class), the features defined in the source text of
that included class are to be made visible as though they had been in
the source text of the including class.
- In the case of library inclusion, all of the names of classes in
that library are to be made visible in the including class. Feature
names within those library classes are subject to the normal rules
regarding classes and class inclusion.
Where a library class is being defined, then all classes within that
library name-space will be visible without the need for an inclusion
clause, although the presence of such a clause is not forbidden.
- Argument substitution
Where an included (partial) class has class arguments, the arguments used
in the inclusion clause type specification shall be subject to macro
substitution for their formal argument equivalents by inclusion. The code
included shall therefore appear as though the arguments given to the
inclusion type specification were those in the source text of the class
being included.
- Feature renaming
- Where it is desired to rename some feature from an included class,
the feature modifier clause indicates how this may be expressed
syntactically. If no name appears after the rename symbol then that
feature cannot be named within the including class or any class which
uses it. It effectively becomes invisible. Note that any renaming
done in this way is to apply not only within the source text of the
including class, but also in the included source text.
- Where it is desired to rename an included library class, the same
result as used for class feature renaming is to apply.
- Visibility modification
- All inclusion is public unless the inclusion clause is specified as
being private. This applies recursively as needed to all features
within classes. When an inclusion clause is private then the
visibility of all features (whether themselves defined as being
private or not) is to be private to the including class.
- Any renamed feature with a visible name is considered to be public
unless the renaming clause indicates that the result shall be private
or readonly.
If a class including some named feature redefines that feature, it
overrides all conflicting methods from included classes. Reader and writer
routines may be redefined, however, there must be no type conflict between the
redefined methods and those included.
WARNING |
The inclusion of classes or libraries may make significant changes
to the type graph and compatibility rule application in the including
class. There are no exceptions to the correctness of definition/uses
type compatibility or type graph consistency caused by inclusion of
any kind. Remember this is only a concrete syntax manipulation. |
Comments
or enquiries should be made to Keith Hopper.
Page last modified: Wednesday, 25 April
2001. |
 |