[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Set & Table hierarchy
- To: <ravi>
- Subject: Set & Table hierarchy
- From: Mark S. Miller <mark>
- Date: Sat, 18 Nov 89 21:10:37 PST
- Cc: <xtech>
- In-reply-to: <Michael>,30 PST <8911160623.AA28675@xanadu>
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