Re: TableView, UnaryFn

[Hugh Hoover <heh>]

...message protocol identical to another...

Well, in this case, the message protocol is more like table than unaryFn,
except for some support stuff in unaryFn (like compose, plus, ...).
The main access method for unaryFn is "Heaper * of (Heaper * something),
where for TableView it is Heaper * fetch (Heaper * something).
  The distiction is that this is a unaryFn masquerading as a Table.  Table
also has a larger protocol than unaryFn (count, iterator, printOn, get) that
needs to be specified somewhere.  The problem with encapsulating a unaryFn
is that it MAY be hanging onto another table - which it will use to respond
to messages like count.  And then again, it may not.  If the generic class
is to respond to a message like count, it needs more information.  
  The answer may be to hang onto more than one unaryFn (one for fetch, one
for count).  

  If the class is more of a replication of unaryFn, then count is simply coded
in the derived class.  This is, in effect, the same as 2 unaryFn's - one
message to respond to fetch (like of()) and other for count.
  It bothers me to replicate the work of unaryFn, but it may be the simplest
answer.  I'm also not enamored of creating new classes left and right to 
handle closure-like things, but again, it may be simplest.
--Hugh