Set & Table hierarchy

[Mark S. Miller <mark>]

Date: Wed, 15 Nov 89 22:23:30 PST
   From: michael (Michael McClary)

   > From ravi Wed Nov 15 20:11:44 1989
   > 
   >       .... while the uses of S&M's are bound to be dominated by the fact
   >       that they have state.  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   > 
   > [Nobody noticed. Too subtle, I guess]

   I noticed.  Found it quite distracting, in fact.  But having nothing to
   comment about, didn't have an opportunity to counter-pun.  Until recently.

   Have markm explain the derivation of "EscorTable".

Michael objected to the Scru/Mu/Immu hierarchy because of the
inability to directly give read-only access to a MuTable.  A pointer
"p" of type "ScruTable *" which happens to point at a MuTable doesn't
do it, because it is considered unexceptional to say "CAST(MuTable,p)"
on such a pointer.  We then realized that this is simply another kind
of Table-view, and that the various Table-views are generally private
subclasses of ScruTable (i.e., clients can ask that they be created
with, e.g., a pseudo-constructor, but not see the class declaration).
(In fact, it is sort of the identity Table-view.)  Nevertheless, we
wished to give this particular class a name.

We realized that this class was a Scru-only table.  Michael suggested
we name it "MassageTable", but then we realized the ambiguity--you can
massage tables that you can change.  Besides, MassageTables aren't
Scru-only.  In addition to scruing, you can also get massaged.  Hence
"EscorTable". 

Clink.