Difference between revisions of "Language Reference/Interfaces"

From wiki.visual-prolog.com
(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>interface::constant</vp>, or by using an open qualification. (See {{lang2|Interfaces|Open_Qualification|Open Qualification}}.)
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><InterfaceDeclaration> :
<vipbnf><InterfaceDefinition> :
   interface <IinterfaceName> <ScopeQualifications> <Sections> end interface <IinterfaceName>-opt</vipbnf>
   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|constantsSection}}
*{{lang2|Constants|Constants_Sections|ConstantsSection}}
*{{lang2|Domains|Domains_Sections|domainsSection}}
*{{lang2|Domains|Domains_Sections|DomainsSection}}
*{{lang2|Predicates|Predicates_Sections|predicatesSection}}
*{{lang2|Predicates|Predicates_Sections|PredicatesSection}}
*{{lang2|Predicates|Predicates_from_Interface|predicatesFromInterface}}
*{{lang2|Predicates|Predicates_from_Interface|PredicatesFromInterface}}
*{{lang2|Directives|Conditional_Compilation|conditionalSection}}
*{{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, and constants can be accessed 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 {{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|interfaceDefinition}} and {{lang2|Implementations|Class_Implementations|classImplementation}}.
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.


Supports is a transitive relation: if an interface <vp>A</vp> supports an interface <vp>B</vp> and <vp>B</vp> in turn supports <vp>C</vp>, then <vp>A</vp> also supports <vp>C</vp>.
<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|interfaceDefinition}} and {{lang2|Implementations|Class_Implementations|classImplementation}}.
<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'''
{{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'''
{{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:

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).
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
Example Consider the following interfaces:
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.