Parameter data types differing by extent (arrays) typically match strictly according to scalar type and extent. However, if the method is called using a parameter with a fixed extent, and no method exists that matches a corresponding parameter with that fixed extent, the call can be resolved by a method definition whose corresponding parameter has an indeterminate extent. In any case, failure to find a match raises a compile-error.

The examples that follow show how different calls to overloaded methods (or constructors) with parameters of the same data type, but with different extents, are resolved:

CLASS Extents:
/* 1 */ METHOD PUBLIC VOID setVal (INPUT piIn AS INTEGER):
        END METHOD.

/* 2 */ METHOD PUBLIC VOID setVal (INPUT piIn AS INTEGER EXTENT 10):
        END METHOD.

/* 3 */ METHOD PUBLIC VOID setVal (INPUT piIn AS INTEGER EXTENT):
        END METHOD.

END CLASS.

When the following procedure calls the setVal( ) method with a given parameter, the overloaded method definition that it matches corresponds to the bold-faced number referenced in the comments:

DEFINE VARIABLE rExt AS CLASS Extents     NO-UNDO.

DEFINE VARIABLE i00  AS INTEGER           NO-UNDO.
DEFINE VARIABLE i10  AS INTEGER EXTENT 10 NO-UNDO.
DEFINE VARIABLE i08  AS INTEGER EXTENT 8  NO-UNDO.
DEFINE VARIABLE ixx  AS INTEGER EXTENT    NO-UNDO.

rExt = NEW Extents( ).

rExt:setVal(42 ). /* Calls 1 - constant integer                    */
rExt:setVal(i00). /* Calls 1 - integer variable                    */
rExt:setVal(i10). /* Calls 2 - fixed array variable of extent 10   */
rExt:setVal(i08). /* Calls 3 - no fixed array variable of extent 8:
                               matches an indeterminate extent     */
rExt:setVal(ixx). /* Calls 3 - indeterminate extent                */