Call an overloaded method or constructor
- Last Updated: October 30, 2020
- 3 minute read
- OpenEdge
- Version 12.2
- Documentation
Calling an overloaded method or constructor is generally the same as invoking non-overloaded methods and constructors, by calling the method or instantiating the class using the correct number of parameters with matching data types and modes.
STATIC option
of the METHOD statement) does not participate in
method overloading. This means that you cannot define both an instance
method and a static method of a class with identical signatures.
Otherwise, the rules for calling overloaded methods apply the same
to both types of methods. However, only instance constructors can
be overloaded because a class can have only one static constructor.
For more information on static methods and constructors, see Define static members.The following fragment of the acme.myObjs.CustObj sample
class defines two overloadings of the printObj( ) method:
|
The following fragment is a part of the Main sample class
modified to invoke these printObj( ) methods depending
on a condition in an IF statement:
|
ABL matches each overload of the method according to its parameters, where
the first version takes no parameters and the second takes an INTEGER input
parameter, which in this case is passed the value 3.
The following fragment of the Main sample class defines
two constructors:
|
This is the driver procedure for the sample classes, Driver.p,
which instantiates Main using each constructor:
|
ABL matches each overload of the constructor according to its
parameters, where the first version takes no parameters and the
second takes a CHARACTER input parameter, which
in this case is passed the filename of a text file containing E-mail
addresses.
In many cases, ABL easily matches overloaded method and constructor calls to their definitions at compile time. However for some overloading scenarios, ABL can match the correct method or constructor to call only at run time, depending on the modes, data types, and values of the parameters involved. For other scenarios, ABL must weigh several valid matches against one another to determine the most appropriate method or constructor to call.
For example, ABL matches an overloaded method call at run time
when a method is passed a dynamic temp-table (TABLE-HANDLE)
parameter and all available overloads of that method are defined
to take different static temp-table (TABLE) parameters.
ABL cannot determine what method to call at compile time because
the passed TABLE-HANDLE parameter has no schema
associated with it to match any of the corresponding static temp-table
parameters defined for the available method overloads. However,
at run time, when the TABLE-HANDLE parameter is
passed with an associated temp-table, ABL can examine the schema
of this temp-table to determine which of the available method overloads
takes a static temp-table parameter with a schema that matches the
schema of the passed temp-table. If it finds a match, ABL then invokes
the matching method. Otherwise, ABL raises a run-time error.
This kind of run-time matching of overloaded method or constructor calls provides a powerful mechanism, similar to polymorphism, that you can use to invoke an appropriate method or constructor that might otherwise require additional code to identify.
For more information on defining overloaded methods and constructors, see Define overloaded methods and constructors. For more information on finer points of method and constructor overloading and how ABL handles some of the more complex overloading scenarios, see Overloaded method and constructor call scenarios.