[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
steppers, tables, pseudoConstructors and encapsulation.
- To: <markm>
- Subject: steppers, tables, pseudoConstructors and encapsulation.
- From: Hugh Hoover <heh>
- Date: Thu, 9 Nov 89 11:18:56 PST
- Cc: <ravi>, <tribble>, <xtech>
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.
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