Please open VirtualBase.lava in LavaPE.
"Mix-in": Specifying a virtual type (rather than a concrete class) as a base type of a new class. (In C++ you can use "templates" to achieve a similar effect, although there is a principal difference between templates and virtual types.)
First remember that the term "virtual base class" has a different meaning in Lava than in C++.
While in other OO languages you can extend only concrete classes/interfaces, Lava allows you to specify virtual types (= type parameters of containing patterns) as base interfaces of a new class.
This unique feature of Lava provides a much more natural and convenient realization of the well-known "decorator" pattern (cf. the frequently cited "Design Patterns" book [8] of the "Gang of Four").
A typical application of the decorator pattern is, for instance, to "decorate" all kinds of windows of a graphical user interface by scrollbars or borders (or first scrollbars and then borders). More precisely:
There is a common base class B of all types of windows. There are special window classes W1, W2, W3, ... that are all derived from B. In order to attach a border to any type of window you need to use only functions that are already declared in B, for instance a function reqSize that computes the "required size" of the respective window, which will, of course, depend on the respective content of that type of window. Therefore reqSize will be overridden by the special window types W1, W2, W3, ..., and the decorator extension DWn of any special window type Wn (which adds the border to Wn) will have to call this overridden Wn-version of reqSize statically.
Actually we could declare and implement the border extension of special window classes without knowing anything about a concrete Wn except that it is derived from B. All we need is a way to specify a type parameter (rather than a concrete type) as a base type of a new type and a way to express a static call of a member function of such a parameter type. Both features are supported by Lava, as is demonstrated by our virtual base sample.
A particular advantage of the Lava solution to the decorator problem is that DWn is a true extension of Wn and thus inherits all features of Wn (including those of B). The solution of [8] establishes the specialized windows Wn as child windows (i.e., as member variables) of the decorated windows DWn. Thus DWn doesn't inherit the features of Wn automatically, but you have to reconstruct them explicitly in DWn by "delegating" the respective function calls to the corresponding functions of the Wn member object of DWn.
Summary: The virtual base types of Lava provide a new kind of abstraction that enables us to specify and implement extension interfaces (in a generic way, "once for all") without knowing the precise concrete type(s) of the base class(es).
Please open VirtualBase.lava in LavaPE.
Read the comments in the declaration tree.
Open the body ("exec") of the initiator "DecoratorDemo".
Look at the different implementations of func, func1, func2.
Run the sample program and watch the outputs (message boxes) that are generated by the successive function calls in the initiator body. They indicate which function version is actually called.