| Previous | Table of Contents | Next |
A qualified name (one of the form <scoped-name>::<identifier>) is resolved by first resolving the qualifier <scoped-name>
to a scope S, and then locating the definition of <identifier> within S. The identifier must be directly defined in S or (if
S is an interface) inherited into S. The <identifier> is not searched for in enclosing scopes.
When a qualified name begins with “::?, the resolution process starts with the file scope and locates subsequent identifiers
in the qualified name by the rule described in the previous paragraph.
Every OMG IDL definition in a file has a global name within that file. The global name for a definition is constructed as
follows.
Prior to starting to scan a file containing an OMG IDL specification, the name of the current root is initially empty (“?)
and the name of the current scope is initially empty (“?). Whenever a module keyword is encountered, the string “::? and the
associated identifier are appended to the name of the current root; upon detection of the termination of the module, the trailing
“::? and identifier are deleted from the name of the current root. Whenever an interface, struct, union, or exception keyword
is encountered, the string “::? and the associated identifier are appended to the name of the current scope; upon detection
of the termination of the interface, struct, union, or exception, the trailing “::? and identifier are deleted from the name
of the current scope. Additionally, a new, unnamed, scope is entered when the parameters of an operation declaration are processed;
this allows the parameter names to duplicate other identifiers; when parameter processing has completed, the unnamed scope
is exited.
The global name of an OMG IDL definition is the concatenation of the current root, the current scope, a “::?, and the <identifier>,
which is the local name for that definition.
Note that the global name in an OMG IDL files corresponds to an absolute ScopedName
in the Interface Repository. (See Section 10.5.1, “Supporting Type
Definitions,? on page 10-12).
Inheritance causes all identifiers defined in base interfaces, both direct and indirect, to be visible in derived interfaces.
Such identifiers are considered to be semantically the same as the original definition. Multiple paths to the same original
identifier (as results
from the diamond shape in Figure 3-1 on page 3-24) do not conflict with each other.
Inheritance introduces multiple global OMG IDL names for the inherited identifiers. Consider the following example:
interface A {exception E {
long L;};void f() raises(E);
};
interface B: A {void g() raises(E);};
In this example, the exception is known by the global names ::A::E and ::B::E.
Ambiguity can arise in specifications due to the nested naming scopes. For example:
interface A {typedef string<128> string_t;};
interface B {typedef string<256> string_t;};
interface C: A, B { attribute string_t Title; // Error: Ambiguous attribute A::string_t Name; // OK attribute B::string_t
City; // OK
};
The declaration of attribute Title in interface C is ambiguous, since the compiler does not know which string_t is desired.
Ambiguous declarations yield compilation errors.