[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Set & Table hierarchy
- To: <mark>
- Subject: Set & Table hierarchy
- From: Eric Dean Tribble <tribble>
- Date: Mon, 20 Nov 89 00:13:02 PST
- Cc: <ravi>, <xtech>
- In-reply-to: <MarkS.Miller'smessageofSat>,22 PST <8911190452.AA04709@xanadu>
Abstract: Response to various points by Ravi about how to organize &
implement the Table and Set hierarchies.
As Dan Ingalls likes to say: "You can cheat as long as you don't get
caught.". I'm thinking in terms of something like the following
ImmuTable : Orgl
MuTable : Waldo
Mu (??) : Bert or Hand
Notice that MuTables would *seem* to be wrappers of Bert-like-things
onto Orgl-like-things, but could have their own protocol identical to
the current MuTable protocol. There doesn't actually have to *be* any
Bert-like-thing or Orgl-like-thing underneath until the client does
something for which these need to be shown. I continue to think that
our plan to have all the implementation classes be the Mu ones is
good, and does not hinder convergence with an Orgls/Berts/Hands/Waldos
You, Hugh, and I talked about this a great deal on the phone while I
was in India...
Even without this, I don't see how to avoid the trick of
copy-on-write-use with backwards deltas. Admittedly it is hairy, but
I don't see how any of the alternatives avoids this hair. This hair
seems fundamental to the whole collection system as we've conceived of
it, independent of whether Immu's are subclasses of Scru's.
I find myself generating tables by accumulating elements. We might
discover we don't need copy-on-x hair. For all the stuff I've
generated, the TableAccumulator could have some very straightforward
efficiency hacks and work just fine. For example, I use an
accumulator to generate and ImmuTable. It could internally have a
MuTable and a copy-flag. The copy-flag is true if a storage-sharing
immutable has been handed out (typically only done after all elements
have accumulated). If there's any possibillity that a returned
ImmuTable might still be around, then it copies the old MuTable and
starts using that.
Besides, ImmuTable may want to be a subclass of Position. If
ImmuTable is a subclass of ScruTable, then ScruTable may want to be
a subclass of Position, which seems grossly inapproriate.
Which brings up the question: Should ImmuTable be a subclass of
Position? If not, what's the representation of a position in a
multi-dimensional coordinate space?
No. No. No. The operations on ImmuTables are unrelated to the
operations on positions. Instead have a subclass of Position that
represents a position in a multi-dimensional space. The fact that it
uses an ImmuTable for implementation is immaterial. We've gone around
this before, but not with the current table/region/etc semantics. Do
we need to?