Instantiate and manage class-based objects

Each class or interface essentially represents a unique data type (object type). ABL supports built-in and user-defined class and interface types in much the same way as built-in primitive types (such as INTEGER). ABL also allows you to manage class-based objects in a similar fashion to handle-based objects (such as procedure, buffer, or query objects), but also supports automatic garbage collection for class-based objects. Thus, you can use class or interface types to define the data types of variables, properties, parameters, and return types. You can also use these data elements as object references to class instances that you create and that ABL (by default) automatically deletes from a session when references to these objects no longer exist.

Similar to ABL handle-based objects, you must create an instance of a class and obtain its object reference before you can reference its data members, properties, methods, or events.

Unlike handle-based objects, you do not reference a class instance using a handle (HANDLE data type). Instead, you use an object reference, which in turn cannot appear in any statement or function that expects a HANDLE data type. You can use any appropriate class or interface data type to define a data element that holds an object reference to a class instance that you create. The particular object type of the object reference determines the class members that you can reference for the given class instance. You can also store the object reference in a temp-table, but not in a database table. The initial value of any object reference you define is the Unknown value (?), which you can change only by assigning another appropriate object reference value.

If you instantiate multiple instances of a class, the ABL session maintains multiple instances of that class. However, as happens with persistent procedure instances, multiple instances of the same class share r-code in memory with a separate data segment for each instance.