Using Caché Objects - InterSystems Documentation

Dynamic Dispatch
22.2 Content of Methods Implementing Dynamic
Dispatch
As the application developer, you have control over the content of dispatch methods. The
code within them can be whatever is required to implement the methods or properties that
the class is attempting to resolve.
Code for dynamic dispatch might include attempts to locate a method based on other classes
in the same extent, package, database, on the same file system, or by any other criteria. If a
dispatch method provides a general case, it is recommended that the method also create some
kind of log for this action, so that there is a record of any continued operation that includes
this general resolution.
For example, the following implementation of %DispatchClassMethod allows the application
user to invoke a method to perform whatever action was intended:
ClassMethod %DispatchClassMethod(Class As %String, Method As %String, args...)
{
WRITE "The application has attempted to invoke the following method: ",!,!
WRITE Class,".",Method,!,!
WRITE "This method does not exist.",!
WRITE "Enter the name of the class and method to call",!
WRITE "or press Enter for both to exit the application.",!,!
READ "Class name (in the form 'Package.Class'): ",ClassName,!
READ "Method name: ",MethodName,!
}
IF ClassName = "" && MethodName = "" {
// return a null string to the caller if a return value is expected
QUIT:$QUIT "" QUIT
} ELSE {
// checking $QUIT ensures that a value is returned
// if and only if it is expected
IF $QUIT {
QUIT $ZOBJCLASSMETHOD(ClassName, MethodName, args...)
} ELSE {
DO $ZOBJCLASSMETHOD(ClassName, MethodName, args...)
QUIT
}
}
By including this method in a class that is a secondary superclass of all classes in an application,
you can establish application-wide handling of calls to non-existent class methods.
188 Using Caché Objects