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

collection classes

Thanks for your feedback.  Here are some more thoughts.

   Date: Fri, 4 Dec 92 13:42:46 -0500
   From: Jeff Piazza <piazza@cambridge.apple.com>


   Also, although add and add! don't *always* specify where new-element
   is inserted, i.e., they don't specify the same location for all
   collections, nonetheless subclasses of <sequence> may specify more
   precise behavior for these functions.  Compare, for example, the
   general description of add! on p.105 and the specific description for
   deques on p.114.

The problem is that it's difficult to cleanly implement default
versions of some of the <sequence> methods without knowing where `add'
inserts it's new-element in the <sequence>.  One could I suppose use
`concatenate' to implement these default method's but using `insert'
would be easier and would also be very useful for other <sequence>
classes.  For example, <stretchy-vector>'s and <list>'s could easily
implement `insert' and I maintain, would add a very useful function.

BTW, given the way sealing goes, it appears to be very difficult to
add new functionality to <sequence>.  Thus it is prudent to consider
exactly what those functions should be.  (BBTW, I think you guys have
done a very good job.)  This is a good segue into the next response.

   Mutability, as described on pp.127-128, refers only to the ability to
   change an individual element of the collection.  These functions would
   additionally require that the sequences being modified be able to
   change their size, something that a simple-vector, for instance, can't

So how do you do `nconc' with lists?  Perhaps there should be a
<stretchy-sequence> abstract class.  It is very useful to have
`concatenate!'.  In fact, I couldn't live without it.  I would also
really like to see the destructive `choose' methods.  It appears that
`insert!' should be a <stretchy-sequence> method as well.

-- jonathan bachrach

31, rue Saint-Merri
F75004 Paris, France