steppers, tables, pseudoConstructors and encapsulation.

[Eric Dean Tribble <tribble>]

Precis: Modularity principles revealed by comparing 'stepper'
pseudo-constructors to 'stepper' member functions to tables, sets,
regions, etc.

I don't feel particularly dogmatic about this (and I haven't seen
anyone else bark).  I only recall one of my two reasons.
Encapsulation requires only that violation of boundaries be explicit.
When a table class creates a stepper for itself, it chooses to reveal
implementation details to the stepper that it creates.  It knows
nothing about the internals of the Stepper except that it might use
some internal methods on the table.  With a stepper
pseudo-constructor, the stepper gets implementation details of the
table without the table's 'knowledge'.  This creates the kind of *invisible*
dependency that modularity principles help us to avoid.

I take it that the same pseudo-constructor would make steppers for
regions, sets, tables, etc?  It occurs to me that one advantage of
using member-functions is that the Table stepper method can be defined
as returning a TableStepper (which has the additional 'key' member
function defined).  Cann pseudo constructors be polymorphic wrt to
return type (I think not)?

Mull that around a bit, then let's talk about it.  Various aspects of
the type mechanism for C++ might place all the right restrictions on
type knowledge.  This issue reminds me of isKindOf vs. double-dispatch
for runtime type checking.

dean