The part resolution rules explain how EGL searches for part names
to resolve references in a program. This is a different process than
the search to resolve a name in an expression, which is described
in Name resolution in an expression.
Part resolution rules apply to the following:
- a variable, field, or parameter declaration based on a part
- a use statement
- an expression where a name cannot be resolved as a field or function
- a property that references a part
There are three important concepts behind part resolution:
- EGL_ROOT
- The EGL_ROOT is a logical container that holds all the parts shipped
with EGL.
- EGL build path
- The EGL build path controls visibility between projects, but also
provides a search order when EGL tries to resolve a part name. The
EGL_ROOT is implicitly added to the end of the path.
- System scope
- The system scope contains a set of EGL parts that can be resolved
without being imported or fully qualified. Currently the only parts
contained within the system scope are those found in the EGL_ROOT.
The system scope allows you to reference a system part, such as the
Record sqlLib.sqlData, without a qualifier
or an import statement:
mySQLDataVar sqlData;
To resolve a fully qualified part name, EGL searches each entry
on the build path to see if it contains the specified package and
part. The first part it finds on the EGL build path is the one it
uses.
To resolve an unqualified part name, EGL gives priority to the
following, in order:
- Single part import
- EGL first attempts to resolve the name by checking the single
part import statements in your source file. For example, the following import statement
resolves the name myLibrary:
import com.companyb.gl.myLibrary;
- You cannot import a part from the default package.
- Current® package
- After checking for single part imports, EGL checks the rest of
your current package for the name. For example, if the previous step
fails and you have a library named myLibrary as part
of your current package, EGL uses that library to resolve the reference.
- On demand import
- EGL searches for each of the packages in the on demand import statements
in all projects on the EGL build path, in order. If it finds a matching
package, it looks in that package for a matching part. If it does
not find the part in that matching package, it keeps searching the
EGL build path for another package with the same name.
- EGL reads all on demand import statements
in your source file during this step. If more than one on demand import statement
resolves the same part name, EGL marks that name as ambiguous. Resolve
this conflict by replacing one or more of the on demand import statements
with a single part import or a fully qualified
part name.
- If there is a myLibrary in the com.companyb.payroll package,
the following code allows EGL to resolve it:
import com.companyb.payroll.*;
- You cannot import a part from the default package.
- System scope
- Only if EGL cannot resolve a part name in any of the previous
steps does it search for a matching part in the system scope.