The following situations involving static type-name syntax can result in name conflicts that cause unexpected behavior or compiler errors:
Naming a variable the same as a class — ABL allows you to have both a class and a variable defined with the same name. This is true even for an object-reference variable that is defined as the given class. However, because variable references take precedence over static type-name references, this can result in hiding static references with unexpected effects. For example, if you have a class, clsName, and define a variable, clsName, any attempt to reference public members of the clsName class raises a compile-time error, because ABL identifies all references to clsName as a variable. Therefore, Progress Software Corporation recommends that you do not name any locally scoped data elements (be they variables, temp-tables, buffers, etc.) the same as a class name.
Type-names used with qualified table field names — In addition to hiding static type name references, variable references hide table field references, and temp-table buffer references hide database buffer references. Because the syntax for many of these references are the same, having identical names for these different references can cause naming conflicts. For example, the following references will result in compile-time errors if you are connected to the Sports2000 database and you try to reference the static MaxValue property on a class type with same syntactic naming as a reference to the:
Customer.Name field as a static Customer.Name:MaxValue reference
Sports2000.Customer buffer as a static Sports2000.Customer:MaxValue reference
Sports2000.Customer.Name field as a static Sports2000.Customer.Name:MaxValue reference
Note that a class type name with three or more dots (.), such as Sports2000.Customer.Name.Security, can never be ambiguous with a database reference, because no database reference can contain more than two dots. Therefore, Progress Software Corporation recommends that you do not use package and class names that might result in type-name references that are syntactically identical to the possible qualified temp-table or database buffer and field references. You can also avoid such ambiguities by ensuring that type names contain a minimum of three dots (.) and that you always use fully qualified type names for static type-name syntax references.
Type-names for classes named as reserved keywords — ABL allows a class to have the name of a reserved keyword. However, ABL does not fully support the use of static type-name syntax for classes whose names are reserved keywords. You can work around this limitation by using a package name to qualify any class whose name is a reserved keyword.
Note: Progress Software Corporation recommends that you always define a class in a package and always qualify the class name with the package name whenever you reference the class type.
Naming a variable the same as a class — ABL allows you to have both a class and a variable defined with the same name. This is true even for an object-reference variable that is defined as the given class. However, because variable references take precedence over static type-name references, this can result in hiding static references with unexpected effects. For example, if you have a class, clsName, and define a variable, clsName, any attempt to reference public members of the clsName class raises a compile-time error, because ABL identifies all references to clsName as a variable. Therefore, Progress Software Corporation recommends that you do not name any locally scoped data elements (be they variables, temp-tables, buffers, etc.) the same as a class name.