Procedure objects support a programming model where you design and instantiate (create) objects based on persistent procedures. These persistent procedures maintain a run-time context that can be accessed by other objects. This run-time context can include variables and various types of handle-based objects that provide the procedure object’s data, and internal procedures, user-defined functions, and named events that provide the procedure object’s behavior.
With procedure objects, the state and behavior in one object has no well-defined relationship to the state and behavior in another. You establish any such relationships at run time by invoking ABL statements to access the state and behavior in another object. You can set up object hierarchies, but again, these relationships depend entirely on statements at run time to maintain these relationships. As a result, you must organize these procedure objects using interfaces that can, without care, easily become inconsistent, and you must manage the lifetimes of these objects individually. You must account for any relationships that you design between them any time that you invoke code to access state or behavior between them.
