| Previous | Table of Contents | Next |
The grammar for the import statement is described by the following BNF:
(100) <import> ::= “import? <imported_scope> “;?
(101) <imported_scope> ::= <scoped_name> | <string_literal>
The <imported_scope> non-terminal may be either a fully-qualified scoped name denoting an IDL name scope, or a string containing
the interface repository ID of an IDL name scope, i.e., a definition object in the repository whose interface derives from
CORBA::Container.
The definition of import obviates the need to define the meaning of IDL constructs in terms of “file scopes?. This specification
defines the concepts of a specification as a unit of IDL expression. In the abstract, a specification consists of a finite
sequence of ISO Latin-1 characters that form a legal IDL sentence. The physical representation of the specification is of
no consequence to the definition of IDL, though it is generally associated with a file in practice.
Any scoped name that begins with the scope token ( “::? ) is resolved relative to the global scope of the specification in
which it is defined. In isolation, the scope token represents the scope of the specification in which it occurs.
A specification that imports name scopes must be interpreted in the context of a well-defined set of IDL specifications whose
union constitutes the space from within which name scopes are imported. By “a well-defined set of IDL specifications,? we
mean any identifiable representation of IDL specifications, such as an interface repository. The specific representation
from which name scopes are imported is not specified, nor is the means by which importing is implemented, nor is the means
by which a particular set of IDL specifications (such as an interface repository) is associated with the context in which
the importing specification is to be interpreted.
The effects of an import statement are as follows:
• The contents of the specified name scope are visible in the context of the importing specification. Names that occur in IDL declarations within the importing specification may be resolved to definitions in imported scopes.
• Imported IDL name scopes exist in the same space as names defined in subsequent declarations in the importing specification.
• IDL module definitions may re-open modules defined in imported name scopes.
• Importing an inner name scope (i.e., a name scope nested within one or more enclosing name scopes) does not implicitly import the contents of any of the enclosing name scopes.
• When a name scope is imported, the names of the enclosing scopes in the fully-qualified pathname of the enclosing scope are exposed within the context of the importing specification, but their contents are not imported. An importing specification may not re-define or re-open a name scope which has been exposed (but not imported) by an import statement.
• Importing a name scope recursively imports all name scopes nested within it.
• For the purposes of this specification, name scopes that can be imported (i.e., specified in an import statement) include the following: modules, interfaces, valuetypes, and eventtypes.
• Redundant imports (e.g., importing an inner scope and one of its enclosing scopes in the same specification) are disregarded. The union of all imported scopes is visible to the importing program.
• This specification does not define a particular form for generated stubs and skeletons in any given programming language. In particular, it does not imply any normative relationship between units specification and units of generation and/or compilation for any language mapping.