How you call a class-based method depends on whether you are calling it from within or from outside the class hierarchy where it is defined. This is similar to internal procedure and user-defined function calls, which must be specified differently when called within the external procedure where they are defined compared to when called from outside the procedure where they are defined. Within the class hierarchy that defines the method, you only have to call the method by name, because ABL implicitly recognizes the method within the environment where it is defined. The same is true with internal procedures and user-defined functions called within the defining procedure.
Note: This section describes method calling mechanisms that apply in common to both instance and static methods and to instance methods in particular. For information on the unique features of calling static methods, see Accessingstatic members.
With respect to another object, within whose class hierarchy a given instance method is defined, you must reference the object along with the method name in order to tell ABL what environment (class instance) contains the method definition. Similarly, when calling an internal procedure or user-defined function from outside of the defining procedure, you use special syntax to reference the procedure where the called routine is defined. Thus, like internal procedures and user-defined functions, the syntax and requirements for calling methods vary depending on where you call them relative to where they are defined.
No matter where you call a method (whether inside or outside the class hierarchy), most other requirements are the same. However, you must invoke any VOID method (that does not return a value) as a statement by itself, where the syntax of method-call depends on where you call the method:
method-call[ NO-ERROR ] .
For any method that returns a value, you have the option of calling it like a VOID method, as a statement by itself (ignoring the return value), or you can include the method call within a run-time expression as part of another statement that relies on the method return value, exactly like a user-defined function. As with user-defined function calls, non-VOID method calls can appear anywhere that a run-time expression can appear, such as a procedure or method INPUT parameter or in the expression of an Assignment (=) statement. For more information on the syntax and the basic requirements for a method-call, see Calling methods from inside a class hierarchy where theyare defined and Calling instance methods from outside a class hierarchy wherethey are defined.
All method calls (VOID or with a return type) are always synchronous. That is, there is no way to call a method asynchronously, as with procedures.
Also, unlike procedures, but exactly like user-defined functions, any run-time arguments passed to a method must, with certain exceptions, have data types that exactly match the data types of the corresponding parameters defined for the method. These exceptions include:
Built-in data types that have an appropriate widening relationship with each other. Otherwise, ABL raises a compiler error. For example, you can pass an INTEGER value as an INPUT parameter defined as DECIMAL, because a DECIMAL parameter can hold all INTEGER values. However, you cannot pass a DATETIME variable as an INPUT parameter defined as DATE without raising a compiler error, because a DATE variable cannot hold the time-value part of the date returned by a DATETIME parameter.
Dynamic and static temp-tables where the run-time schema of the dynamic temp-table matches the static temp-table definition. Otherwise, the AVM raises a run-time error.
Dynamic and static ProDataSets where the run-time schema of the dynamic ProDataSet matches the static ProDataSet definition. Otherwise, the AVM raises a run-time error.
Class or interface types that can appropriately represent one another. Otherwise, ABL raises a compiler error. For more information, see Passingobject reference parameters.
Note: If the parameter is a class or interface type, the object instance is passed by reference as an object reference. The effect of passing an object reference parameter is identical to assigning one object reference variable to another. For more information, see Defining an object reference parameter.
A literal Unknown value (?) passed for any built-in data type.
An expression whose data type cannot be known until run time, when the parameter data types are validated. If they do not match, the AVM raises a run-time error.
The compiler verifies that the parameters passed in the method invocation are consistent with the parameters defined for the method. The compiler verifies that the number and mode of these parameters match exactly, and that the data types match appropriately. There is no implicit conversion of any data types when passing method parameters, except for those with appropriate widening relationships. However, provided that the run-time schemas match, ABL does allow a dynamic temp-table or ProDataSet to be passed to static temp-table or ProDataSet parameter (respectively), and similarly for passing a static temp-table or ProDataSet to a corresponding dynamic temp-table or ProDataSet parameter.
In addition to the data types, the number and mode of the parameters passed to a method must match the method’s definition. In other words, the method signature of the called method must match the signature of a method definition. In fact, because multiple methods can be defined in any class hierarchy with the same name (overloaded), at a minimum, ABL must be able to uniquely match method calls and method definitions only by their respective signatures (parameter lists). Depending on the difference in method signatures, the appropriate method can be identified at either compile time or run time. Otherwise, ABL raises a compiler or run-time error, as appropriate. For more information on the criteria for passing parameters to methods, see the Parameter passing syntax reference entry in OpenEdge Development: ABL Reference.
The following sections describe the syntax and requirements for calling methods inside or outside the class hierarchy where they are defined. For more information on calling class methods, see the Class-based method call reference entry in OpenEdge Development: ABL Reference. For more information on calling overloaded methods, see Calling an overloaded method or constructor.
Built-in data types that have an appropriate widening relationship with each other. Otherwise, ABL raises a compiler error. For example, you can pass an INTEGER value as an INPUT parameter defined as DECIMAL, because a DECIMAL parameter can hold all INTEGER values. However, you cannot pass a DATETIME variable as an INPUT parameter defined as DATE without raising a compiler error, because a DATE variable cannot hold the time-value part of the date returned by a DATETIME parameter.
