Matching dynamic and static temp-table or ProDataset parameters

If methods or constructors are overloaded with one dynamic and several static data object (temp-table or ProDataSet) parameters, a passed dynamic data object matches any corresponding static data object parameter whose schema definition is identical to the schema of the dynamic data object passed at run time. If no static data object overloading matches the passed dynamic schema exactly, the AVM invokes the method or constructor that is overloaded with the corresponding dynamic data object parameter. For a passed dynamic temp-table or ProDataSet parameter, failure to find a match raises a run-time error. A passed static data object similarly matches any identical static data object parameter, and otherwise matches the corresponding dynamic data object parameter. For a passed static temp-table or ProDataSet parameter, failure to find a match raises a compile-time error.

The following examples show how matching combinations of static and dynamic data object parameters resolves calls to overloaded methods (or constructors). These examples use temp-table parameters, but would work the same way using equivalent ProDataSet parameters.

The example that follows shows a class that defines a method, setTable( ), which is overloaded only by different types of static temp-table (TABLE) parameters; the setTable( ) method is then called by other method definitions that illustrate a variety of parameter matching scenarios:

With method Scenario1( ), the invocation of method setTable( ) invokes the first version of setTable( ) taking an INPUT temp-table with a Customer table schema. In this scenario, the caller passes a static temp-table and the called method has a matching static temp-table parameter definition.

With method Scenario3( ), the AVM cannot identify a method to run because the compiler and AVM cannot determine what version of setTable( ) taking an INPUT temp-table parameter is most appropriate. The handle that is passed as a parameter does not have a schema associated with it. Therefore, the AVM is unable to match the invocation to any one of the overloaded methods. The AVM raises a run-time error identifying this ambiguity.

This example shows a class that defines a method, setTable( ), which is overloaded by different combinations of parameter modes and types of temp-table parameters, where one is a dynamic temp-table (TABLE-HANDLE) parameter. As in the previous example, the method is called by other method definitions that illustrate a variety of parameter matching scenarios:

CLASS DataObjectOverloads:
  DEFINE TEMP-TABLE ttCustomer LIKE Customer NO-UNDO.
  DEFINE TEMP-TABLE ttOrder LIKE Order       NO-UNDO.

  METHOD PUBLIC VOID setTable(INPUT TABLE ttCustomer):    /* first */
  END METHOD.

  METHOD PUBLIC VOID setTable(OUTPUT TABLE ttOrder):      /* second */
  END METHOD.

  METHOD PUBLIC VOID setTable(INPUT TABLE-HANDLE ttHndl): /* third */
  END METHOD.

  METHOD PUBLIC VOID Scenario1( ):
    CREATE ttOrder.
    setTable(OUTPUT TABLE ttOrder).
  END METHOD.

  METHOD PUBLIC VOID Scenario2( ):
    DEFINE VARIABLE hTT AS HANDLE NO-UNDO.

    CREATE TEMP-TABLE hTT.
    hTT:CREATE-LIKE("Customer").
    hTT:TEMP-TABLE-PREPARE("Customer").
    setTable(TABLE-HANDLE hTT).
  END METHOD.

  METHOD PUBLIC VOID Scenario3( ):
    DEFINE VARIABLE hTT AS HANDLE NO-UNDO.

    CREATE TEMP-TABLE hTT.
    hTT:CREATE-LIKE("Order").
    hTT:TEMP-TABLE-PREPARE("Order").
    setTable(TABLE-HANDLE hTT).
  END METHOD.

  METHOD PUBLIC VOID Scenario4( ):
    DEFINE VARIABLE hTT AS HANDLE NO-UNDO.
    CREATE TEMP-TABLE hTT.
    setTable(TABLE-HANDLE hTT).
  END METHOD.

  METHOD PUBLIC VOID Scenario5( ):
    DEFINE VARIABLE hTT AS HANDLE NO-UNDO.

    CREATE TEMP-TABLE hTT.
    setTable(OUTPUT TABLE-HANDLE hTT).
  END METHOD.
END CLASS.

With method Scenario1( ), the invocation of method setTable( ) invokes the second version of setTable( ) taking an OUTPUT temp-table with an Order table schema. In this scenario, the caller passes a static temp-table and the called method has a matching static temp-table parameter definition.

With method Scenario2( ), the invocation of method setTable( ) invokes the first version of setTable( ) taking an INPUT temp-table with a Customer table schema. In this scenario, the caller has a dynamic temp-table, which at run time is populated with a schema that matches the Customer table. At compile time, no determination can be made concerning what version of setTable( ) to invoke; the decision is delayed until run time. At run time, because a match is made against a method version defined with a static temp-table parameter, this method is chosen over the more general method taking the TABLE-HANDLE parameter.

With methods Scenario3( ) and Scenario4( ), the invocation of method setTable( ) invokes the third version of setTable( ) taking an INPUT TABLE-HANDLE. In this scenario, the caller has a dynamic temp-table, which is being passed with a mode that does not match the method that would otherwise qualify (the second version), or which at run time is populated with a schema that does not match a version of the method defined with a static temp-table parameter. At compile time, no determination can be made concerning which version of setTable( ) to invoke; the decision is delayed until run time. At run time, because no match is made against a static temp-table parameter, the TABLE-HANDLE version of the method is chosen.

With method Scenario5( ), the invocation of method setTable( ) invokes the second version of setTable( )taking an OUTPUT temp-table with an Order table schema. In this scenario, the caller has a dynamic temp-table, which at run time has no schema associated with it. The determination is made at compile time based upon the fact there is only one version of setTable( ) that has an OUTPUT temp-table parameter. At run time, during the invocation of the method, the table is populated with the Order table schema.