EDT:Language Overview03

EGL packages and type-name resolution

An EGL package is a container of EGL types, each of which has a name that is unique to the package. For example, a program and a data item of the same name cannot be in the same package. In general terms, the package is a namespace, which is a container in which the immediately subordinate names are unique.

The package corresponds to a set of subfolders in a directory. The subfolders correspond to the package name.

Package names

A package name is a sequence of names with intervening periods (.). Here is an example:

com.myOrg.myPkg

Each name is that of a subfolder in a hierarchy. The hierarchy for the current example is expressed as follows on a Windows platform:

com\myOrg\myPkg

The EGL parts are in files in the bottommost subfolder; here, the myPkg subfolder.

You might invert the list of qualifiers in your company's Internet domain name and assign the resulting list to the start of your package names. For example, if the domain name is mycompany.mydivision.mydepartment.com, you might start your package names with com.mydepartment.mydivision.mycompany. This convention is often used. A benefit is that your packages will be unique even if your company merges or collaborates with another.

Package names are case sensitive; myPkg is different from MYpkg.

To avoid unpredictable results, do not create a package with any of the following names:

• egl.lang.reflect
• egl.lang.reflect.mof
• egl.lang.reflect.reftypes
• eglx.http
• eglx.java
• eglx.javascript
• eglx.json
• eglx.jws
• eglx.lang
• eglx.persistence
• eglx.persistence.sql
• eglx.rbd
• eglx.rest
• eglx.services
• eglx.ui
• eglx.ui.rui
• eglx.xml
• eglx.xml.binding.annotation
• org.eclipse.edt.eunit.runtime
• org.eclipse.edt.mof.egl
• org.eclipse.edt.mof.egl.sql

Although a package corresponds to a set of subfolders, an EGL package is a collection of types. The subfolders and related files represent only how those types are stored.

Package statement

Each EGL source file in a named package must start with a statement that identifies the package. The statement provides a kind of documentation, as in the following example:

package myPkg;

Default package

An Eclipse project includes a default package, which is a package that has no name. Other packages cannot access the types that are defined in a default package.

When you use a default package, the directory that contains the package includes all the EGL source files that are in that package. In this case, a source file does not start with a package statement.

Package import 

The EGL import statement provides access to the types in a second, named package. The import statement is used in two ways:

• A statement that explicitly provides access to a specific part in a package in called a one-type import statement. The type is always available at compilation time.
  
  Here is an example statement:

import myPkg.MyProgram;

• A statement that provides access to a set of types in a package is called an on-demand import statement because the types that are actually required are made available only as needed.
  
  Here is an example statement:

import myPkg.*; 

The example makes available all the types in the myPkg package.

An import statement can give access to types that are in another package repository, which is a directory or compressed file that holds one or more packages. Access requires that you reference the package repository in the EGL build path, which is a list of repositories.

Type-name resolution

The rules for type-name resolution define the search order that the compiler follows to resolve a type reference; for example, in a variable declaration. The compiler considers the current package directory and the repositories in the EGL build path. The compiler stops the search only when the same-named type is found or, if no type is found, only after all locations are searched.

The rest of this description assumes that the compiler is seeking the myType type in the myPkg package. Also, change "current project" to "current directory" if the search occurs in the EGL SDK.

If the reference is fully qualified, as in the case of myPkg.myType, the compiler seeks the type in the current project and then in every repository in the EGL build path. The search through the repositories is in build-path order.

If the reference is not fully qualified, as in the case of myType, the compiler gives priority to packages in the following order:

1. The package identified in a one-type import statement such as
   import myPkg.myType;
   
   The compiler seeks the type in the current project and then in every repository in the EGL build path, in build-path order.
   
   
2. The current package.
   
   The compiler seeks the type in the current project and then in every repository in the EGL build path, in build-path order.
   
   
3. The package identified in an on-demand import statement such as
   import myPkg.*;.
   
   The compiler seeks the type in the current project or directory and then in every repository in the EGL build path, in build-path order. The search ends as soon as a type is found. However, if multiple on-demand import statements reference the same type, the search results in an error.

♦ Next: Syntax and scope

♦ Previous: Types and values