Restrictions

We place several restrictions on the definition of accessory functions. Most are needed to prevent ambiguities that prevent us from selecting between dynamic and static dispatch at compile time.

• For any function, at most one parameter (including the receiver object) may be virtual. This is necessary to ensure that we do not need multiple dispatch. Here and in the remainder of this paper, we count the receiver object of a method as a parameter.

• No single scope can contain two functions that differ only in the dispatch mechanism of a parameter: We cannot have f(Exp &) and f(virtual Exp &). This restriction is necessary because it would not be possible to distinguish calls to the two functions. C++ has an analogous rule for virtual functions.

• In any one scope, no two functions with the same name and arity (number of arguments) are dynamically dispatched on different parameters. This will play an important role in our function selection semantics below.

• All functions with parameters of class C must be defined before the execution of code that creates an object of class C. In traditional C++ environments, all functions are defined before program execution begins, and this restriction always holds. In environments that allow dynamic loading of classes (such as Java) this places restrictions on the relative timing of object creation and the loading of functions.

• To ease implementation in C++, we only allow accessory functions for classes that already have at least one virtual function: For example, we cannot have f(virtual int &), as int has no dispatch table.