🚀 go-pugleaf

From article <11701@boulder.Colorado.EDU>, by scotth@boulder.Colorado.EDU (Scott Henninger):
> |>From: hopper@ntmtv.UUCP (Ian Hopper)
> |
> |I have always felt that some form of Garbage Collection is
> |needed in order to do a decent job on reusable "Collection"
> |modules.  Since the current favorite language (C++) does
> |not consistiently (or easily) support GC, we do not see
> |good quality collection modules.
> 
> Quality in what sense? Program efficiency? Cognitive efficiency (i.e. how
> readable it is)? Correctness? Reliability?
> 
> -- Scott
>    scotth@boulder.colorado.edu

That is a perfectly reasonably question, given my vague posting.
Sorry to waste your time on the first pass. (Novice poster.)
All of your suggesions apply, I would say.  Performance can be an
application specific issue, so is GC.

I interpret "quality" in a reusable package to mean: lack of internal 
bugs and an interface that allows the package to be used without hassles.
Typical hassles are listed as items 2-5 below.

The (unstated) question I am getting at is: do we need to assume 
mark-and-sweep-like garbage collection in order to write siginificant 
amounts of reusable software?

One disclaimer: I don't have a copy of the Gorlan "OOPS" C++ library,
so I am forced to speculate on what is available from it.  I did not
wish to imply that it (or any other particular library) is broken or
"bad", rather that such "good" implementations are difficult, and there
are very few of them around.  Only OOPS is in a language without a 
standard garbage collector.  The others have GC's: Smalltalk and Eiffel.
Eiffel has a GC, but the classes suffer from the fixed-at-creation
problem my "PS" was referring to.  Smalltalk may not have the 
performance that some applications need and lacks static type checking.

I believe that one of the following apply to a reusable collection "mocule":

	1) There is a mark-and-sweep garbage collector available.

	I claim this is "best", provided you can afford GC.  I know
	if several GC's that ease the "hiccups" that the classic M-S
	approach required.

	2) The library implements a mark-sweep garbage collector.
	   Perhaps restricting the gc capability to objects that
	   comply with some restrictions.

	This is OK, but there are restrictions on use.  M-S garbage
	collectors are often not portable.

	3) The library uses some form of reference counting and punts the
	   problem of circular references to the client of the library.

	If circular references are provably not a problem for the
	particular case, then this is perfect.  Again, there may
	be additional restrictions on what sorts of objects can be
	put into a collection. (SubClass of: ReferenceCountableObject.)

	4) The library copies collection elements into and out of the
	   collection objects.
	
	This is slow for contents that are large objects in their own right.
	Putting an object into and then retrieving that object creates
	a copy, rather than the original object.  This may be inappropriate.
	Objects cannot tell whether they are a member of a collection,
	except by value.  Membership in multiple collections is not
	easily represented, except by value.

	5) The collection class forces it's users to carefully track
	   the "ownership" of objects.  This makes it difficult to
	   allow an object to be a member of a varying number of 
	   collections without extra book-keeping.

	The source of many subtle bugs in user's code.  I believe that
	this is the "typical" approach.

(Still :) Interested in responses,

	Ian