[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Table class hierarchy



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