Object Oriented Classes and References¶

• Object Oriented Classes and References
  • Introduction
  • Support in FWD
  • Configuration and Setup
  • Skeleton Classes
    • What is a Skeleton Class?
    • Why Skeleton Classes Are Needed
    • Configure the Location
    • Place the Skeletons
    • Contents of a Skeleton Class or Interface
    • Enhancing the Skeletons
    • Generating .NET Skeletons
  • Class Map
    • Format
    • Example
    • Tool for Generation of the class_map.xml

Introduction¶

Starting in OpenEdge v10, it became possible to write 4GL code structured as objects. This object oriented approach provides subset of OO support in traditional OO languages, including the ability to define a class and create instances (individual objects) of those classes. When creating new OO 4GL code, that code must be put into .cls source files using new OO syntax for defining classes, methods, properties and so forth.

These new classes will exist in the source tree of your project, along with the traditional procedural 4GL code, but the OO code will be organized into packages of hierarchical directories. Any 4GL code that references these classes will either use a fully qualified (package + classname) name or will use the non-qualified class name. Either way, when such references are encountered, the parsing of the referencing source file is paused while an attempt is made to find the class. In v11 partially qualified names can be referenced, but this is not supported by FWD yet. If the referenced class cannot be found, then the parsing of the current file will fail. Conversely, if the class is found, then that class is parsed and any referenced classes are searched for and parsed until the entire graph of referenced classes has been loaded. At that point the parsing of the original source file can continue.

Considering that the code is integrated into the rest of the project sources, the Progress approach was to search through the PROPATH to find fully qualified matches OR to check if an unqualified class name matched the class name portion of an explicitly specified USING statement OR to substitute the unqualified name into any USING specifications that have a wildcard and search the PROPATH for a match.

Most of the 4GL language still can only be accessed using existing non-object syntax. However, there is a small amount of functionality which has been created in built-in OO 4GL classes (e.g. Progress.Lang.Object) that can be accessed and subclassed just like other classes in the application. When classes need to be found, these built-in classes are also searched. The difference is that these classes don't reside in the application directories or PROPATH.

Starting in OpenEdge v11, this same OO syntax can be used to access .NET objects. Those .NET objects can be in .NET assembies or can be from the built-in .NET classes. Searches for classes must handle these additional possible matches.

It is this class resolution or searching process that needs special attention and configuration in order to properly parse OO 4GL code. This chapter provides guidance on how to configure the conversion project to handle these cases.

Support in FWD¶

Since FWD v3.1, FWD provides parsing and analytics support for OO 4GL and 4GL code referencing .NET objects. This support was improved in subsequent versions. As of FWD v4.0, full conversion and runtime support is available for OO 4GL code including the ability to directly reference Java classes. .NET classes are not supported at conversion time.

The work for OO 4GL support was largely completed in #3751 and the remaining items are in process in #4373 (final development tasks for core OO 4GL support) and in #4384 (support for a range of common built-in OO 4GL classes). There is quite a lot of detail available in these tasks in regard to the implemention of both the conversion and the runtime support.

Supported Built-in OO 4GL ClassesSupported Built-in OO 4GL Classes