Translating Double Dispatch into Single Dispatch

Abstract

Goals of flexibility and re-usability in typed object-oriented languages suggest the requirement of double dispatch, i.e., the mechanism of dynamically selecting a method not only according to the run-time type of the receiver (single dispatch), but also to the run-time type of the argument. However, many mainstream languages, such as, e.g., C++ and Java, do not provide it, resorting to only single dispatch. In this paper we present a general technique for adding double dispatch as a type-safe language feature, so yielding dynamic overloading and covariant specialization of methods, without extending basic semantics. To this aim we introduce a toy core language, extended to a full form of (non encapsulated) multi methods. Then we define a translation algorithm from multi methods to the core language, that implements double dispatch by using only standard mechanisms of static overloading and single dispatch. As a main feature, our translation preserves type safety, it uses neither RTTI nor type downcasts and does not introduce crucial overhead during method selection.

Featherweight Java with multi-methods

“…We already did some work on multi-methods as a language extension of C++ (see [7,8]). In particular, the software doublecpp, http://doublecpp.sf.net, is based on a preprocessor that, given a program written in the extended C++, produces an equivalent program in standard C++, by applying a program transformation based on the double dispatch technique ( [30,26]).…”

Reflection-based implementation of Java extensions: the double-dispatch use-case.

“…For instance, they could wish to have a double-dispatch mechanism to ease implementations dealing with tree-like structures or binary methods [4,17]. This feature, which is a special case of multi-methods [11,21,8,3,22,23,10,12,1,27,2,14], allows a method implementation to be chosen with respect to the dynamic type (late-binding) of both the receiver and a single argument. It can be achieved programmatically through the visitor design pattern [19,15].…”