Re: TableView, UnaryFn

[Hugh Hoover <heh>]

While having a TableView hold onto a UnaryFn seems simple initially, I have
problems with it.  First, it must actually hold onto 2 (at least).  One to
respond to fetch() and another to respond to count(), and well, perhaps
another to respond to enclosure() and another to respond to coordinateSpace().

  I think I've answered my question, thanks.

TableView is an abstract class defining the basic view protocol.  Specific
TableViews will be instances of subclasses of TableView.
  Now, the question is whether TableView needs the compose(), plus(), diff(),
getSlice(), tableTransform() and restrict() protocols.
  2 options: 1) implement these protocols to allow views of views that 
provide different mappings, or,
  2) have the developer compose UnaryFns in like manner to implement the
specific function required.

I favor approach 2).  flexible and avoids needless code.  Why not just
encapsulate UnaryFn's?   Because the protocol is too large and number of
Fns required for each TableView is too variable.
  I think we need a good style for their use, however.  A set of standard
views that can be customized quickly would be useful.  This also applies to 
UnaryFns, Predicates and BinaryFns.  I've found that I've duplicated work
specifying Predicates that already existed.  It there a good way to coordinate
the proliferation of "standard" functions?

--Hugh.