Our design suggests to express every operation of a type as a
class itself. We are used to these operations being defined within the
scope of the type. There is no reason to modify this hierarchical
presentation. It follows that operation classes should ideally be
nested within the scope of the type of which they are members, and
which is usually different from that of their initiator.
Such a systematic use of nested types is uncommon: types are often
considered to build global taxonomies, in the linnean (and
aristotelician) tradition - Eiffel does not even support nested types
[Meyer 88].
The type of the encompassing class is used to type the equivalent
of the this pointer (the self-reference in C++ classes), which, in the
absence of direct language support, is to be passed explicitly to
operations at construction time. It should be obvious that this leads
to complications if we consider specializing these classes and their
member operations by derivation. The relation between the types
(enclosing and nested) is covariant and a typical case of the dual
hierarchy mentioned earlier (in 1.2.3.c)