22.1. Adding Functionality

The primary purpose of bolt-ins is to add or enhance functionality. There are three ways in which this can be achieved. First, it may be new functionality, which is then accessible to derived classes and/or client code of the composite type.

Second, it may be the replacement of existing functionality. This can be via the well-known C+ mechanism of run time polymorphism [Stro1997], whereby derived class may override the virtual methods of their parent class(es). However, it is also possible to override nonvirtual functions. This is known as function hiding, which usually constitutes an abuse of the class whose methods are being hidden, and is a likely source of bugs [Meye1998, Dewh2003]. However, there are some circumstances in which it is safe and quite reasonable to do this, which we cover in this chapter.

Last, it may be providing functionality that does not yet exist. This can be achieved by two obverse techniques: run time polymorphism of abstract types and simulated compile-time polymorphism (see section 22.5). Where the former prescribes behavior that must be provided by inheriting classes, the latter prescribes behavior that must be supplied by the inherited class.

If this is all as clear as vegetable soup, worry not: it will be strained to a light consommé in this chapter.