Accessory Functions

Although no current single-dispatch language does so, it is in principle possible to allow dynamic dispatch on a parameter other than the receiver of the message. We call a function that does so an accessory function of the class involved in dispatch. Figure 2 shows how accessory functions can be used to add a dynamically dispatched interpret function to our A.S.T. example of Figure 1 (using a notation based on C++). The rest of this section gives our design goals, and gives possible syntax and semantics for integrating accessory functions into a C++$\;$-like language.

Figure 2: Accessory Function Example

Our goal is to provide the following properties of programs written with accessory functions:

• Accessory functions can be added to a group of classes without editing (or even reading) the source for the classes. To avoid violated the principle of data encapsulation, accessory functions do not have access to the private data of any classes they are not listed in. For example, the interpret functions of Figure 2 do not have access to the private data of any class, including the classes for the abstract syntax tree.

• New classes can be added to a program that uses accessory functions without any need to edit existing functions or classes. In other words, we wish to allow both reuse in a function (the previous item) and reuse by inheritance.

• Accessory functions can be dispatched as efficiently as other single dispatch functions, such as virtual functions in C++.

• Except for the change in which argument is used for dynamic dispatch, function dispatch should follow the rules that exist in the language.

• The system must be able to produce errors about dispatch before the program is executed: A user must not see ``method not found'' errors while running a program (this was a design goal of C++).