Parametrized classes and interfaces

3 steps must be distinguished when working with parameterized classes/interfaces:

1. Precompilation of a parameterized class/interface

2. Usage of a parameterized class/interface

3. Expansion of a parameterized class/interface

Precompilation of a parameterized class/interface takes place without any knowledge of the current parameters. One aim here is to detect syntax errors. The other is to store the interface and the source text of the parameterized class/interface in the repository (see the section "I/O for repositories"). The status of the source text, the status of the COPY elements and the status of the compiler directives (see the section "Source data input") which the compilation unit of the parameterized class/interface addresses are recorded at the time precompilation takes place and are used for the later usages and expansions (i.e. subsequent modifications to these statuses have no affect on the usage and expansion).

The usage of parameterized classes/interfaces takes place in the compilation unit using EXPANDS clauses in the REPOSITORY paragraph. As a result new, concrete classes/interfaces are created. These consist of the current parameters specified in the compilation unit and of the repository data recorded during precompilation. The concrete classes/interfaces behave like non-parameterized classes/interfaces. Their characteristics are included in the user’s compilation of the parameterized classes/interfaces.

The expansions are initiated automatically following the user of the parameterized classes/interfaces or, in the case of compilation groups, after the last compilation unit. Here all concrete classes/interfaces which result from the usage of parameterized classes/interfaces are compiled. Only the data of the parameterized class/interface and the current parameters (including their repository data) are used for this purpose. No further source texts, library elements, etc. are required for the expansions. All the compiler options (see the chapter "Controlling the compiler via SDF") which are valid for the compilation unit of the user of parameterized classes/interfaces are, as with compilation groups, also effective for the subsequent expansions. However, no source listing is created in the case of expansions. The effect of >>IMP directives is not suppressed. In contrast, compiler directives which apply for users of parameterized classes/interfaces have no influence on subsequent expansions.

Further details on parameterized classes/interfaces are provided in the “COBOL2000 Reference Manual” [1].

Example 2-9

Precompilation of a parameterized class

Source code

CLASS-ID. pkl USING fp.———————————————————————————————————————————— (1)
...
REPOSITORY.
    CLASS fp.
...
01 obj-fp USAGE OBJECT REFERENCE fp.
01 obj-pkl USAGE OBJECT REFERENCE pkl.
...

Assignment and call to compiler

/ADD-FILE-LINK REPOUT,REPOSITORY——————————————————————————————————— (2)
/START-COBOL2000-COMPILER ————————————————————————————————————————— (3)
/ ... UPDATE-REPOSITORY=*YES ...——————————————————————————————————— (4)

(1)	The name of the parameterized class is pkl, the name of a formal parameter is fp.
(2)	The library REPOSITORY is assigned to incorporate the repository data.
(3)	Precompilation takes place using the COBOL2000 compiler; the compiler automatically recognizes whether precompilation is to be performed - no additional control is required for this.
(4)	The repository data is stored as an X element with the name PKL$PCL (see the section "COMPILER-ACTION option").

Example 2-10

Usage of a parameterized class

Source code

PROGRAM-ID. n.
...
REPOSITORY.
    CLASS pkl
    CLASS exp EXPANDS pkl USING ap ———————————————————————————————— (1)
    CLASS ap.
...
01 obj-exp USAGE OBJECT REFERENCE exp.
...

Assignment and call to compiler

/ADD-FILE-LINK REPLIB,REPOSITORY —————————————————————————————————— (2)
/START-COBOL2000-COMPILER ... ————————————————————————————————————— (3)

(1)	The name of the expansion of the parameterized class is exp, the name of the current parameter is ap.
(2)	The repository data of the precompiled parameterized class pkl and of the (non-parameterized) class ap is expected in the library REPOSITORY.
(3)	Compilation of n is followed automatically by the compilation of the concrete expansion exp of the parameterized class pkl.

 

In the event of dependencies between various expansions (example: the expansion of a parameterized class is used as the current parameter for another expansion), the input repository must also be assigned as output library and the UPDATE-REPOSITORY=*YES option must be set when the user is compiled.

Example 2-11

Expansion of a parameterized class

Source code temporary created  ——————————————————————————————————————— (1)
CLASS-ID. exp USING ap.  —————————————————————————————————————————— (2)(3)
...
REPOSITORY.
    CLASS ap.  ——————————————————————————————————————————————————————— (3)
...
01 obj-fp USAGE OBJECT REFERENCE ap.  ———————————————————————————————— (3)
01 obj-pkl USAGE OBJECT REFERENCE exp.  —————————————————————————————— (2)
...

(1)	Generation and compilation take place automatically. The user does not need to enter any additional commands or statements for this purpose.
(2)	The name of the parameterized class is replaced in all places by the name exp of the concrete expansion.
(3)	The name of the formal parameter is replaced in all places by the name ap of the current parameter.

The compiler does not have to perform the subsequent expansions in the order in which they have been written in the program, but in such a way that the data required for the current parameters is available before the expansion takes place.