Re: Container Library?

[Michael van Acken <mvacken@t-online.de>]

> Date: Mon, 27 Apr 1998 09:42:33 -0500
> From: "Mark K. Gardner" <mkgardne@rtsl3.cs.uiuc.edu>
> [...]
> I just realized where our differences are. There are two prominent
> philosophies concerning the design of class libraries typified by
> either having an single root to the class hierarchy (i.e., Object) or
> multiple roots. If I am not mistaken, you are implicitly assuming that
> all classes that we would want to put into lists are extensions of
> Object and hence "no" adapter classes are required. On the other hand,
> I am making no assumptions about the ancestry of a class, which
> typifies the multiple root philosophy.

There are certainly different ways to put this.  But I agree with
you. 

> MVA> b) provide (e.g.) a `Copy' procedure in module `LinkedList' that
> MVA>    creates a duplicate of a given list; the specs of `Copy': the new
> MVA>    list has the same contents as the first list, in the same order,
> MVA>    but any destructive operation (like element removal) on the first
> MVA>    list will not be visible in the copy
> MVA>
> MVA> I don't see how this can be achieved by a user-defined `DataElement'
> MVA> type.  But then, this may be a kind of subjective blindness :-)
> 
> Ah... we are working with Turing complete languages. There is always a
> way. It just may not be convenient! :) 
> [example of cloned list elements removed...]

Maybe I wasn't specific enough.  Of course I was looking for an "easy"
way.  And with "same" element I did not mean a copy (NEW+assign) of a
heap object.  Actually I wanted to have one heap object P appear in
both lists after the copy, that is, I wanted both lists to have an
element referring to a single instance of P.

> I think Michael has convinced me that the single root model is the way
> to go in terms of simplicity, ease of use, and reduction in "user
> lines of code". It even has a successful precedent in Smalltalk.

Actually I'm thinking more in terms of LISP here.  We are talking
about lists, after all.  And LISP made list processing an art (excuse
the pun).  The flexibility of the LISPish approach is hard to beat.

> [There is still this nagging concern in the back of my mind that some
> have found the single root model to not scale well to large projects,
> but I am satisfied since I do not do large projects.] ;)

And I have a nagging feeling that it's a bad idea to mix user data and
maintenance data in a single class, at least in a library module
designed to be of general use.  Hey, we might just introduce a data
type ANYREC and have both, flexible lists and multiple roots.  (Ok,
I'm just kidding.)

> Next item of discussion, should all containers be extensions of an
> abstract container type as in Smalltalk? What should such a type look
> like?

I would like to see some comments on this, too ;-)

-- mva