|
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: Monday, 29 May 2000.
|
|