This section describes a set of rules that determine how EGL identifies the part to which a name refers. These rules are important in the following situations:
A second set of rules determine how EGL resolves variable references. For details, see References to variables and constants.
In the simplest case, you define parts one after the next in a single package, without declaring one part within another. The following list omits many details, but shows a series of parts that are at the same hierarchical level:
Function: Function01 Function: Function02 Function: Function03 Record: Record01
Parts at the same level are available to one another. Function01, for example, can invoke one or both of the other functions; and Record01 can be used as a typedef for variables in each of the three functions.
In most cases, a part cannot nest another part. The exceptions are as follows:
An example with nested parts is as follows:
Program: Program01 Function: Function01 Function: Function02 Function: Function03 Record: Record01
Parts at the top level are available to every other part in the package. However, the nested parts (Function01 and Function02) are available only to a subset of parts in the package:
Finally, if your code includes text or print forms, a use declaration is necessary to access the form group that includes those forms. A use declaration is also desirable when accessing data tables or libraries. For additional information, see Use declaration.
Most development efforts have parts that are shared across more than one package. These rules are in effect:
You can provide access in these ways:
my.package.myPart
To resolve a part reference, EGL conducts a search that includes one to many steps. The following statements apply at each step:
These situations are possible:
As noted earlier, you can specify the name of a package when referencing a part, as in the example my.package.myPart. The current project is considered, as are any projects listed in the EGL build path.
If the reference is from a part that is inside the same package, the following statements apply:
If a part references a part other than a function and does not specify a package name, the steps in the search order are as follows:
Each import statement in this case explicitly references a particular part in a particular package. The part named in such an explicit-type import statement acts as an override of the same-named part in the current package.
If you have identically named packages in two different projects, a given explicit-type import statement uses the EGL build path to do a first-found search, stopping when the required part is found. (The part must be unique to a package in a given project.) The presence of a same-named package in two different projects is not an error, but creates a confusing situation and is not recommended.
An error occurs if you have two explicit-type import statements that name the same part.
Each import statement in this case references all parts in a given package and is called a wild-card import statement.
If you have identically named packages in two different projects, a given wild-card import statement uses the EGL build path to do a first-found search, stopping when the required part is found. (The part must be unique to a package in a given project.)
If more than one wild-card import statement retrieves the same-named part, an error occurs.
If a part invokes a function and does not specify a package name, the steps in the search order are as follows:
The search of the included functions occurs as follows:
Each import statement in this case explicitly references a particular part in a particular package. The part named in such an explicit-type import statement acts as an override of the same-named part in the current package.
If you have identically named packages in two different projects, a given explicit-type import statement uses the EGL build path to do a first-found search, stopping when the required function is found. (The function must be unique to a package in a given project.) The presence of a same-named package in two different projects is not an error, but creates a confusing situation and is not recommended.
An error occurs if you have two explicit-type import statements that name the same part.
Each import statement in this case references all parts in a given package and is called a wild-card import statement.
If you have identically named packages in two different projects, a given wild-card import statement uses the EGL build path to do a first-found search, stopping when the required part is found. (The part must be unique to a package in a given project.)
If more than one wild-card import statement retrieves the same-named part, an error occurs.
When a program is invoked on a call or transfer statement, the argument list of the invoker must match the parameter list of the invoked program. A mismatch of argument and parameter causes an error.
Related concepts
EGL projects, packages, and files
Import
Introduction to EGL
Parts
References to variables and constants
Related reference
EGL build path and eglpath
EGL editor
EGL source format
Use declaration
(C) Copyright IBM Corporation 1992, 2005. All Rights Reserved.