Difference between revisions of "Language Reference/Interfaces"
m (1 revision(s)) |
m (header levels) |
||
Line 32: | Line 32: | ||
All sections contained (transitively) in conditional sections must also be of those kinds. | All sections contained (transitively) in conditional sections must also be of those kinds. | ||
== The interface: object == | === The interface: object === | ||
If an interface does not explicitly support any interfaces, then it implicitly supports the build-in interface ''object.'' | If an interface does not explicitly support any interfaces, then it implicitly supports the build-in interface ''object.'' | ||
Line 40: | Line 40: | ||
The purpose of ''object'' is to be a universal base-type of all objects. | The purpose of ''object'' is to be a universal base-type of all objects. | ||
== Open Qualification == | === Open Qualification === | ||
Open qualifications are used to make references to class level entities more convenient. The open section brings the names of one scope into another scope, so that these can be referenced without qualification. | Open qualifications are used to make references to class level entities more convenient. The open section brings the names of one scope into another scope, so that these can be referenced without qualification. | ||
Line 53: | Line 53: | ||
open <ScopeName>-comma-sep-list</vipbnf> | open <ScopeName>-comma-sep-list</vipbnf> | ||
== Supports Qualification == | === Supports Qualification === | ||
Supports qualifications can only be used in {{lang2|Interfaces|Interfaces|interfaceDefinition}} and {{lang2|Implementations|Class_Implementations|classImplementation}}. | Supports qualifications can only be used in {{lang2|Interfaces|Interfaces|interfaceDefinition}} and {{lang2|Implementations|Class_Implementations|classImplementation}}. |
Revision as of 23:03, 14 October 2008
An interface definition defines a named object type. Interfaces can support other interfaces. See Supports Qualification for further details.
All predicates declared in an interface are object members in objects of the interface type.
An interface is also a global scope, in which constants and domains can be defined. Thus constants and domains defined in an interface are not part of the type that the interface denotes (or of objects having this type).
Such domains and constants can be referenced from other scopes by qualification with the interface name: interface::constant, or by using an open qualification. (See Open Qualification.)
InterfaceDeclaration : interface IinterfaceName ScopeQualifications Sections end interface IinterfaceName-opt
InterfaceName : LowerCaseIdentifier
The InterfaceName in the end of the construction must (if present) be identical to the one in the beginning of the construction.
The ScopeQualifications must be of the kinds:
The Sections must be of the kinds:
All sections contained (transitively) in conditional sections must also be of those kinds.
The interface: object
If an interface does not explicitly support any interfaces, then it implicitly supports the build-in interface object.
The object is an empty interface, i.e. it contains no predicates etc.
The purpose of object is to be a universal base-type of all objects.
Open Qualification
Open qualifications are used to make references to class level entities more convenient. The open section brings the names of one scope into another scope, so that these can be referenced without qualification.
Open has no effect on the names of object members as these can only be accessed by means of an object anyway. But names of class members, domains, functors, and constants can be accessed without qualification.
When names are brought into a scope in this way it may happen that some names becomes ambiguous (see Scoping).
Open sections have only effect in the scope in which they occur. Especially this means that an open section in a class declaration has no effect on the class implementation.
OpenQualification : open ScopeName-comma-sep-list
Supports Qualification
Supports qualifications can only be used in interfaceDefinition and classImplementation.
Supports qualifications are used for two things:
- specifying that one interface A extends another interface B and, thereby, that the object type A is a subtype of the object type B
- declaring that the objects of a certain class "privately" have more object types, than the one specified as construction type.
Supports is a transitive relation: if an interface A supports an interface B and B in turn supports C, then A also supports C.
If an interface does not explicitly support any interfaces, then it implicitly supports the predefined interface object.
Functionally, it makes no difference whether an interface supports a certain interface more that once (directly and/or indirectly), but it might make a representational difference for the objects.
When supports is used in the implementation of a class, the result is that "This" not only can be used with the construction type, but also with any privately supported object type.
SupportsQualification : supports InterfaceName-comma-sep-list
SupportsQualification can only be used in interfaceDefinition and classImplementation.
Notice interfaces cannot be used together in a supports qualification, if they have conflicting predicates.
Predicates are conflicting if they have the same name and the arity but different origin interfaces.
The origin interface of a predicate is the interface in which the predicate is literally declared, as opposed to interfaces where it is indirectly declared by a supports qualification.
So it does not give conflicts, if the same interface is met twice or more in the supports chains.
Example
Consider the following definitions and declarations:
interface aaa predicates insert : (integer X) procedure (i) end interface interface bbb supports aaa predicates insert : (integer X, string Comment) procedure (i,i) end interface interface cc supports aaa predicates extract : () -> integer procedure () end interface interface dd supports aaa, bbb, cc predicates extract : (string Comment) -> integer procedure (i) end interface
Here is a list of all predicates found in dd (found by a depth traversal):
predicates insert : (integer) procedure (i). % dd -> aaa insert : (integer) procedure (i). % dd -> bbb -> aaa insert : (integer, string) procedure (i,i). % dd -> bbb insert : (integer) procedure (i). % dd -> cc -> aaa extract : () -> integer procedure (). % dd -> cc extract: : (string) -> integer procedure (i). % dd
Some of the predicates are the same, so all in all, dd will contain the following members:
predicates insert : (integer) procedure (i). % origin interface: aaa insert : (integer, string) procedure (i,i). % origin interface: bbb extract : () -> integer procedure (). % origin interface: cc extract : (string) -> integer procedure (i). % origin interface: dd
Example
Consider the following interfaces:
interface aaa predicates insert : (integer X) procedure (i). end interface interface bbb predicates insert : (integer X) procedure (i). end interface interface cc supports aaa, bbb % conflicting interfaces end interface
The interface cc is illegal, because insert/1 supported in aaa has aaa as origin, whereas insert/1 supported in bbb has bbb as origin.