EGL part resolution rules

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. For more information, see "The EGL build path" in the EGL Programmer's Guide.
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.