[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Table class hierarchy
- To: <ravi>
- Subject: Table class hierarchy
- From: Hugh Hoover <heh>
- Date: Thu, 9 Nov 89 16:21:22 PST
- Cc: <xtech>
The suggestions you made in your note (Nov 9, 10:33:40 1989) suggests
the following detailed hierarchy (including implementation classes)
-----------ScruTable --------------
/ \ \
MuTable ---- ImmuTable TableView
/ \ /|\
HashTable IntegerTable ... ...
|
Vector
|
WordVector
In discussion, we covered the following points.
1) The ImmuTable class is a single class which has the same protocol as
MuTable, with the important difference that a change operation on an
ImmuTable always (in effect) creates a new table, where the same
operation on a MuTable always changes the table.
IUm still not sure I like this, mostly because the MuTable protocol does
not imply copying, so that it is possible to misunderstand the difference
and use the MuTable / ImmuTable distinction incorrectly. If the ImmuTable
change protocol is different, it will help clarify the distinction.
2) The second point is that WordVector (at least) is properly a subclass
of MuTable because of the gutsOf() operation. Because of this
implementation efficiency hack, we are allowing the programmer access to
the internals of the table, allowing them to change the table. This
implies we cannot guarantee immutability and therefore we should not
assert what we cannot guarantee. I agree with this, WordVector should
be a kind of MuTable. It does mean more work though...
--Hugh