There are parallels between a class hierarchy and the super procedure mechanism in ABL. Super procedures provide some aspects of inheritance and delegation. For example, if the classes acme.myObjs.Common.CommonObj, acme.myObjs.CustObj, and acme.myObjs.NECustObj were implemented as ABL procedures, then the startup code for NECustObj.p could run CustObj.p and CommonObj.p persistently, and use the ADD-SUPER-PROCEDURE handle-based method to create a super procedure chain linking the three running procedure instances. The procedures could implement some of the same internal procedures or functions that correspond to the original class methods, and pass control from one level to the next higher level using the RUN SUPER statement or the SUPER built-in function. As described in a previous section, a key aspect of this technique is that all the associations are established at run time, so that the ABL compiler has no opportunity to validate the correctness of references between the procedures, as it can with the corresponding classes. Of course, without strong typing, procedures cannot be defined as abstract or implement interfaces. So, the typical way to manage different implementations of the same code base for procedures is to compile them with different versions of include (.i) files.

Class inheritance provides this functionality through more conventional object-oriented syntax, in a framework of strong typing and compile-time validation. Using one technique or the other is a choice that you have to make when you begin the design of an application module that is made up of multiple related procedures or classes. Whatever your choice, you cannot use the super procedure mechanism in classes, and you cannot build a class hierarchy from procedures.

For a comparison of class-based and procedure objects separately implemented using corresponding classes and procedures, see Compare constructs in classes and procedures.