steppers, tables, pseudoConstructors and encapsulation.

[Hugh Hoover <heh>]

During the discussions yesterday, one of the items we passed quickly over
was the use of pseudoConstructors for steppers rather than an explicit
message in tables (stepper) to get a stepper on a table.  After thinking
about this a bit more, I will still defend the pseudo-constructor approach.
  Here's why:

  If there is a stepper message in the table classes, each table knows the
"best" kind of stepper to create for themselves.  At least they must know
>some< appropriate kind of stepper.  This then requires that the table classes
know something of the stepper classes.  This is ok, because they really only
need to know a little.  (unless there is a very special stepper optimized
for a particular table class).
  On the other hand, steppers must know something about the table implementation
to be able to >efficiently< step over the table  (This is already the case
for HashTables - where the stepper for them knows about 2 extra table methods
created for stepping, and HashTableEntries).  I know that a stepper can be
created without breaking any encapsulation, but it would require a lot more
run-time work.  My point here is that in order to get the best efficiency,
one class needs to know a fair amount about the other (which I accomplish
by having the stepper use the implementation class directly, rather than
knowing only about MuTable).  If the stepper already knows a fair amount,
then the stepper pseudoconstructor can also know which stepper is best for
a particular table class, and fall back to a general implementation when it
can't identify a particular table.
  I think this approach is essentially the same as a table message (just
reverse the points-of-view) and a bit more practical, in that steppers know
more about tables than tables know about steppers.
  A counter to this argument is that a particular table class can know
generally what kind of stepper is best (IntegerTableStepper for IntegerTables,
wow!) without knowing anything more.
  The question is, is there a real, non-dogmatic reason to go one way or the
other?
--Hugh