archives

Open Multi-Methods for C++

Peter Pirkelbauer, Yuriy Solodkyy, and Bjarne Stroustrup. Open Multi-Methods for C++. Proc. ACM 6th International Conference on Generative Programming and Component Engineering (GPCE). October 2007.

Multiple dispatch – the selection of a function to be invoked based on the dynamic type of two or more arguments – is a solution to several classical problems in object-oriented programming. Open multi-methods generalize multiple dispatch towards open-class extensions, which improve separation of concerns and provisions for retroactive design. We present the rationale, design, implementation, and performance of a language feature, called open multi-methods, for C++ . Our open multi-methods support both repeated and virtual inheritance... ...our approach is simpler to use, catches more user mistakes, and resolves more ambiguities through link-time analysis, runs significantly faster, and requires less memory. In particular, the runtime cost of calling an open multimethod is constant and less than the cost of a double dispatch (two virtual function calls). Finally, we provide a sketch of a design for open multi-methods in the presence of dynamic loading and linking of libraries.

Who said C++ isn't evolving?

The discussion in section 4 of the actual implementation (using EDG) is particularly detailed, which is a bonus.

J&: Nested Intersection for Scalable Software Composition

J&: Nested Intersection for Scalable Software Composition by Nathaniel Nystrom, Xin Qi, Andrew C. Myers. 2006.
We identify the following requirements for general extension and composition of software systems:
  1. Orthogonal extension: Extensions may require both new data types and new operations.
  2. Type safety: Extensions cannot create run-time type errors.
  3. Modularity: The base system can be extended without modifying or recompiling its code.
  4. Scalability: Extensions should be scalable. The amount of code needed should be proportional to the functionality added.
  5. Non-destructive extension: The base system should still be available for use within the extended system.
  6. Composability of extensions.
The first three of these requirements correspond to Wadler’s expression problem. Scalability (4) is often but not necessarily satisfied by supporting separate compilation; it is important for extending large software. Non-destructive extension (5) enables existing clients of the base system and also the extended system itself to interoperate with code and data of the base system, an important requirement for backward compatibility. Nested inheritance addresses the first five requirements, but it does not support extension composition. Nested intersection adds this capability.
Compare this approach to one taken by Scala (or read the section 7).

Early vs. late binding dogma/experiences?

Seeking to learn from other's experience:

I'm probably a knee-jerk static kind of person (SML, Java) but have heard plenty of smart folks extoll the virtues of late binding [1] [2]. And I think I'm even seeing those once-pretty-static places have to loosen up for pragmatic software development/engineering reasons [3] [4].

What is a good middle ground, theoretically? Where is a good middle ground, in terms of a concrete language or system available today?

thank you.