Booch "forms" and child packages [was: AQ&S Guidance on pragma Elaborate_Body]

["John G. Volan" <johnvolan@sprintmail.com>]

Apologies for following up my own post, but I had a thought:

John G. Volan wrote:
> 
> This suggests that iterators might be better off in a _child_ package.
> The iterator type could still see the implementation details of the
> stack type, but the original stack package wouldn't be "cluttered" with
> this extra concept of an iterator.  This way, iterators are optional: If
> an application needs them, it can "with" the child package; if it
> doesn't need them, it won't have to pay the cost of having the iterator
> code linked in.

One of the problems I had with the old Booch components was how Booch's
notion of "forms" introduced so much duplication of code into his ADT
library.  For instance, one dimension of form Booch considered was
whether an ADT package included support for iterators or not.  For every
package that did provided iterators, there would be another one that
didn't.  Often times both packages would be identical except for the
iterator stuff.  This must present something of a configuration
nightmare if you're the maintainer of the ADT library.  Multiply this by
all the various "form" dimensions Booch identified, and you get a
combinatorial explosion of slightly different versions.

I can see why Booch had to do this: Features such as iterators are
really optional, so clients ought to be allowed to select whether they
want all that baggage included into their applications or not.  In
Ada83, with its flat library space, the only recourse was to have
duplicate packages providing slightly different versions of the same
ADT.

In Ada95, you can avoid this problem (in some cases) by exploiting
Ada95's hierarchical library space: For instance, as I described above,
you can write a base ADT package without iterators, and then support the
iterator concept in a child package.  The iterator child package doesn't
duplicate any code from the parent ADT package, it just adds whatever
extra is needed to support this extra concept (and can exploit knowledge
of the private implementation details of the ADT in order to do so). 
Yet this arrangement still gives clients all the flexibility they need:
If they only need the base ADT, that's all they need to "with"; if they
also need iterators, they can "with" the child package, too. 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------