Booch's book Software Components with Ada, established a standard for the encapsulation of objects in Ada packages. Normally, the operations on objects are classified into two categories, constructors and selectors. However, Booch expanded upon this classification by including a third category, iterators. An iterator is defined by Booch as "an operation that permits all parts of an object to be visited". Throughout his book Booch addresses the development of iterators over various objects, but due to the nature and goals of the book, the construction and potential uses of iterators in Ada packages are never fully developed.
We take a slightly different view of iterators. Instead of viewing iterators as a third category of operations on objects, we view iterators as an intermediate building block, a reusable tool, that may be used to fabricate constructors and selectors.
Unfortunately, Booch's book established a precedent on how iterators are viewed by the Ada community. This precedent is continued with another set of commercially available components, the GRACE components from EVB Software Engineering. As such, both the Booch and GRACE components contain at most one iterator per data structure. In fact, there are several possible iterators for most data structure. For example, both the Booch and GRACE components supply only one iterator for binary trees. The iterator is a depth first iterator. It is easy to demonstrate that there are at least 14 standard variations of depth first iterators and several other families of binary tree iterators.
In several papers we built upon the concept presented by Booch and demonstrates that some care must be taken to build iterators in order to make them more versatile to potential users of the packages that contains them. The result of providing more useful iterators a potentially greater amount of low and intermediate level software reuse. Iterators also encourages the decomposition of certain algorithms in a standardized fashion leading to improved software readability.
The full use of iterators stand as a lost opportunity to the Ada83 community. Perhaps it is time to revisit this subject and, perhaps, learn some lessons about the encapsulation of reusable components and tools that may provide insight into reuse at other levels.
Further, Ada9X presents us with new opportunities. In particular, many of the new features in Ada9X provide new approaches to encapsulation that allow us, under many circumstances, to avoid the use of generics and limited private types, two features that are at the heart of safe encapsulation in Ada83. How will these new features simplify the client's use of encapsulated components and tools?