Difference between revisions of "Language Reference/Interfaces"
SergeMukhin (talk | contribs) |
(References) |
||
(10 intermediate revisions by the same user not shown) | |||
Line 7: | Line 7: | ||
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). | 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: <vp> | Such domains and constants can be referenced from other scopes by qualification with the interface name: <vp>interfaceName::constant</vp>, or by using an open qualification. (See {{lang2|Interfaces|Open_Qualification|Open Qualification}}.) | ||
<vipbnf>< | <vipbnf><InterfaceDefinition> : | ||
interface < | interface <InterfaceName> | ||
<ScopeQualifications> | |||
<Sections> | |||
end interface <IinterfaceName>-opt</vipbnf> | |||
<vipbnf><InterfaceName> : | <vipbnf><InterfaceName> : | ||
<LowerCaseIdentifier></vipbnf> | <LowerCaseIdentifier></vipbnf> | ||
See also {{lang|Generic Interfaces and Classes|Generic Interfaces and Classes}} and {{lang|Monitors|Monitors}}. | |||
The <vpbnf><InterfaceName></vpbnf> in the end of the construction must (if present) be identical to the one in the beginning of the construction. | The <vpbnf><InterfaceName></vpbnf> in the end of the construction must (if present) be identical to the one in the beginning of the construction. | ||
Line 24: | Line 29: | ||
The <vpbnf><Sections></vpbnf> must be of the kinds: | The <vpbnf><Sections></vpbnf> must be of the kinds: | ||
*{{lang2|Constants|Constants_Sections| | *{{lang2|Constants|Constants_Sections|ConstantsSection}} | ||
*{{lang2|Domains|Domains_Sections| | *{{lang2|Domains|Domains_Sections|DomainsSection}} | ||
*{{lang2|Predicates|Predicates_Sections| | *{{lang2|Predicates|Predicates_Sections|PredicatesSection}} | ||
*{{lang2|Predicates|Predicates_from_Interface| | *{{lang2|Predicates|Predicates_from_Interface|PredicatesFromInterface}} | ||
*{{lang2|Directives|Conditional_Compilation| | *{{lang2|Properties|Properties_Sections|PropertiesSection}} | ||
*{{lang2|Directives|Conditional_Compilation|ConditionalSection}} | |||
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. | ||
Line 44: | Line 50: | ||
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. | ||
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 | 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 {{lang2|Basic_Concepts|Scoping_&_Visibility|Scoping}}). | When names are brought into a scope in this way it may happen that some names becomes ambiguous (see {{lang2|Basic_Concepts|Scoping_&_Visibility|Scoping}}). | ||
Line 55: | Line 61: | ||
=== Supports Qualification === | === Supports Qualification === | ||
Supports qualifications can only be used in {{lang2|Interfaces|Interfaces| | Supports qualifications can only be used in {{lang2|Interfaces|Interfaces|<vpbnf><InterfaceDefinition></vpbnf>}} and {{lang|Implementations|<vpbnf><ClassImplementation></vpbnf>}}. | ||
Supports qualifications are used for two things: | Supports qualifications are used for two things: | ||
Line 62: | Line 68: | ||
*declaring that the objects of a certain class "privately" have more object types, than the one specified as construction type. | *declaring that the objects of a certain class "privately" have more object types, than the one specified as construction type. | ||
<vp>supports</vp> is a transitive relation: if an interface <vp>A</vp> <vp>supports</vp> an interface <vp>B</vp> and <vp>B</vp> in turn <vp>supports</vp> <vp>C</vp>, then <vp>A</vp> also <vp>supports</vp> <vp>C</vp>. | |||
If an interface does not explicitly support any interfaces, then it implicitly supports the predefined interface ''object''. | If an interface does not explicitly support any interfaces, then it implicitly supports the predefined interface ''object''. | ||
Line 68: | Line 74: | ||
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. | 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 "<vp>This</vp>" not only can be used with the construction type, but also with any privately supported object type. | When <vp>supports</vp> is used in the implementation of a class, the result is that "<vp>This</vp>" not only can be used with the construction type, but also with any privately supported object type. | ||
<vipbnf><SupportsQualification> : | <vipbnf><SupportsQualification> : | ||
supports <InterfaceName>-comma-sep-list</vipbnf> | supports <InterfaceName>-comma-sep-list</vipbnf> | ||
<vpbnf><SupportsQualification></vpbnf> can only be used in {{lang2|Interfaces|Interfaces| | <vpbnf><SupportsQualification></vpbnf> can only be used in {{lang2|Interfaces|Interfaces|<vpbnf><InterfaceDefinition></vpbnf>}} and {{lang|Implementations|<vpbnf><ClassImplementation></vpbnf>}}. | ||
'''Notice''' interfaces cannot be used together in a supports qualification, if they have conflicting predicates. | '''Notice''' interfaces cannot be used together in a supports qualification, if they have conflicting predicates. | ||
Line 83: | Line 89: | ||
So it does not give conflicts, if the same interface is met twice or more in the supports chains. | 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: | |||
Consider the following definitions and declarations: | |||
<vip>interface aaa | <vip>interface aaa | ||
Line 127: | Line 131: | ||
extract : () -> integer. % origin interface: cc | extract : () -> integer. % origin interface: cc | ||
extract : (string) -> integer. % origin interface: dd</vip> | extract : (string) -> integer. % origin interface: dd</vip> | ||
}} | |||
{{Example| Consider the following interfaces: | |||
Consider the following interfaces: | |||
<vip>interface aaa | <vip>interface aaa | ||
Line 147: | Line 150: | ||
The interface <vp>cc</vp> is '''illegal''', because <vp>insert/1</vp> supported in <vp>aaa</vp> has <vp>aaa</vp> as origin, whereas <vp>insert/1</vp> supported in <vp>bbb</vp> has <vp>bbb</vp> as origin. | The interface <vp>cc</vp> is '''illegal''', because <vp>insert/1</vp> supported in <vp>aaa</vp> has <vp>aaa</vp> as origin, whereas <vp>insert/1</vp> supported in <vp>bbb</vp> has <vp>bbb</vp> as origin. | ||
}} |
Latest revision as of 12:00, 25 October 2012
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: interfaceName::constant, or by using an open qualification. (See Open Qualification.)
InterfaceDefinition : interface InterfaceName ScopeQualifications Sections end interface IinterfaceName-opt
InterfaceName : LowerCaseIdentifier
See also Generic Interfaces and Classes and Monitors.
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:
- ConstantsSection
- DomainsSection
- PredicatesSection
- PredicatesFromInterface
- PropertiesSection
- ConditionalSection
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.
interface aaa predicates insert : (integer X). end interface interface bbb supports aaa predicates insert : (integer X, string Comment). end interface interface cc supports aaa predicates extract : () -> integer. end interface interface dd supports aaa, bbb, cc predicates extract : (string Comment) -> integer. end interface
Here is a list of all predicates found in dd (found by a depth traversal):
predicates insert : (integer). % dd -> aaa insert : (integer). % dd -> bbb -> aaa insert : (integer, string). % dd -> bbb insert : (integer). % dd -> cc -> aaa extract : () -> integer. % dd -> cc extract: : (string) -> integer. % dd
Some of the predicates are the same, so all in all, dd will contain the following members:
predicates insert : (integer). % origin interface: aaa insert : (integer, string). % origin interface: bbb extract : () -> integer. % origin interface: cc extract : (string) -> integer. % origin interface: dd
interface aaa predicates insert : (integer X). end interface interface bbb predicates insert : (integer X). 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.