Try OpenEdge Now
skip to main content
Object-oriented Programming
Overloaded Method and Constructor Calling Scenarios : Matching the Unknown value (?) to parameters
 

Matching the Unknown value (?) to parameters

When passing the Unknown value (?) for a given parameter, ABL only selects a method or constructor to invoke if the Unknown value (?) causes no compile-time ambiguity among overloadings. If there are multiple methods or constructors with corresponding parameters being passed the Unknown value (?), ABL raises a compile-time ambiguity error. You can avoid ambiguity with the Unknown value (?) by converting it to a known data type using a data type conversion function or by assigning it to a variable, data member, or property, then passing the converted value, variable, data member, or property as the parameter.
The following example shows one overloaded method call using the Unknown value (?) without ambiguity and another overloaded method call using the Unknown value (?) with ambiguity:
CLASS Unknown:
  METHOD PRIVATE INTEGER setUnknowns (INPUT pcName AS CHARACTER,
                                      INPUT piPos  AS INTEGER):
    RETURN 1.
  END METHOD.

  METHOD PRIVATE INTEGER setUnknowns (INPUT pcName  AS CHARACTER,
                                      INPUT pcLocal AS CHARACTER):
    RETURN 2.
  END METHOD.

  METHOD PUBLIC VOID test ():
    DEFINE VARIABLE iReturn AS INTEGER.

    iReturn = setUnknowns(?, 12).     /* 1 */
    iReturn = setUnknowns("Frank", ?). /* 2 */
  END METHOD.
END CLASS.
The two calls to these methods resolve as follows, according to the bold-faced code comments:
1. The first passed parameter with the Unknown value (?) matches the first parameter of either method. However, because the passed parameter value of 12 for the second parameter can match only the second INTEGER parameter of the first method version, ABL matches the call to this first version.
2. The second passed parameter with the Unknown value (?) matches the second parameter of either method. Because the passed parameter value of "Frank" for the first parameter can also match the first parameter of either method, ABL cannot choose a match and raises a compile-time ambiguity error.
However, the following procedure calls the same methods in the previous Unknown class without ambiguity, because it ensures that every Unknown value (?) parameter is converted to a specific data type:
DEFINE VARIABLE rUObj    AS CLASS Unknown NO-UNDO.
DEFINE VARIABLE iUnknown AS INTEGER       NO-UNDO.

rUObj = NEW Unknown( ).

rUObj:setUnknowns("Bill", STRING(?)). /* 1 */

iUnknown = ?.
rUObj:setUnknowns("Steve", iUnknown). /* 2 */
The two calls to these methods resolve as follows, according to the bold-faced code comments:
1. Passes an Unknown value (?) converted to the CHARACTER data type for the second parameter using the STRING built-in function. ABL therefore matches the second version of the setUnknowns( ) method, whose second parameter is defined as a CHARACTER
2. Passes an Unknown value (?) converted to the INTEGER data type by first assigning the Unknown value (?) to an INTEGER variable, then passing this variable as the second parameter value. ABL therefore matches the first version of the setUnknowns( ) method, whose second parameter is defined as an INTEGER.