Try OpenEdge Now
skip to main content
Object-oriented Programming
Getting Started with Classes, Interfaces, and Objects : Class definition files and object type names : Defining and referencing object type names

Defining and referencing object type names

A class file, together with its filename and location, defines the type of a given user-defined class or interface. You can refer to this class or interface type using an object type name that you define using either a CLASS statement or an INTERFACE statement, depending on the object type. You specify an object type name for both class and interface types using this syntax.


[ " ][package.]class-or-interface-name [ " ]
Element descriptions for this syntax follow:
A period-separated list of names that, along with class-or-interface-name, uniquely identifies the class or interface among all accessible classes and interfaces in your application environment. These names correspond to the directory names in a valid path name that is relative to PROPATH, where each name is identical to a directory name in the path, and each forward (/) or backward (\) slash separator in the path is replaced with a period (.). The relative path name represented by package specifies the location of the class file that contains the class or interface definition. Any package specification must remain constant between compile time and run time, and must be complete (cannot correspond to a partial path name above the directory containing the class file). An object type name without a package refers to a class or interface whose definition can be found directly on PROPATH. If package contains embedded spaces, you must enclose the entire object type name specification, including class-or-interface-name, in quotes.
Note: Do not place a class file in a directory whose name contains a period (.) character. ABL interprets the component after the period as another directory level and therefore will not find the referenced class file.
The name of the class or interface. This name must exactly match the filename of the class file (excluding its .cls or .r extension) that contains the definition for the specified class or interface. This class file must be located in the relative path represented by package (if specified). The class-or-interface-name must begin with an alphabetic character and it cannot contain any periods or spaces. This name thus represents the unqualified name of a defined class or interface.
Once you define a class or interface type, you can reference it by using its fully qualified object type name (including its package) or, when an appropriate USING statement is specified, by using its unqualified class or interface name (without its package). For more information on the USING statement, see Referencing an object type name without its package.
Note that both elements of an object type name (package and class-or-interface-name) must conform to the case sensitivity requirements of the operating system (e.g., UNIX or Windows). On a case-sensitive OS, only the first reference to the object type name must be case correct. ABL follows this initial letter case for all subsequent references to the type.
For example, the first reference on UNIX to a class with the type name, topdir.subdir.SomeClass, must be found at compile time in the source file, SomeClass.cls, in the directory, topdir/subdir, that is relative to PROPATH. If the class is compiled and saved, its r-code must also be found at run time in the file, SomeClass.r in the same directory path, topdir/subdir relative to PROPATH. If you later reference an object type name with the letter case specified by Topdir.Subdir.SomeClass, ABL considers this type name to reference the same object type that you initially referenced as topdir.subdir.SomeClass and matches it accordingly.
Note: The requirement to maintain a constant relative path between compile time and run time applies only to class files (not to procedure files).
For more information on object type names, see the Type-name syntax reference entry in OpenEdge Development: ABL Reference.
* Valid and invalid object type name references
* How object type names are used to locate type definitions on PROPATH