The CTBASE package is a set of basic components that provide core functionalities needed to create more complexe software. One may think of the CTBASE components as molecules that can be combined to make more complexe chemicals. CTBASE components are implemented with an object-oriented approach, mainly by applying the principle of encapsulation. CTBASE components must be instantiated via a constructor sub-procedure before they can be used. Furthermore, they can only be used through a well-defined set of sub-procedures, which are commonly called methods in C++ and Java circles. That's about as far as it goes in terms of the object-oriented-ness of the CTBASE package. But the point is not to try accessing the internal data of components despite having access to the source code and thus being privy to how they are implemented. Using objects through their defined interfaces (that is through their defined set of functions) is what object-oriented-ness is about and it is with this principle in mind that the CTBASE components were developped.
A word on passing pointers to sub-procedures
In RPG, when working exclusively with basic data types, certain assumptions can be made; one of these assumptions is that the language will clear an ALPHA buffer of its previous content before assigning it a new value. Such assumptions cannot hold when passing pointers to buffers in sub-procedure calls. In other words, using pointers to buffers as parameters is not the same as passing ordinary buffers such as Data Structures or ALPHA fields to sub-pocedures. Be sure to understand this point before using the CTBASE package. More detailed information with examples is available under each component description in the Clara-Doc.
Compiling and linking (binding)
We do not impose any restriction as to how one may compile and use the resulting module objects. Each component could be compiled as modules and statically linked to programs. Or modules could be linked as a service program. In this case, service program signatures and export sources are at the initiative of the developper. Clarasoft will however garanty that versions will always be backward compatible from the standpoint of method prototypes, data structures and other definitions. Once a sub-procedure is defined, it will never be changed, not even with additional optional paramters. Rather, a new sub-procedure will be defined if a new paramter is needed.