[gclist] Guardians

[Carl Bruggeman]

--------
> > We
> > concluded, as many people on list list probably have by now, that
> > there is no way to automatically determine the order in which
> > finalization should occur because there are cases when the order is
> > program dependent rather than topologically dependent (assuming
> > finalization actions are not severely restricted, e.g., freeing
> > storage for an object in its destroy method in C++).
> 
> Some of us isn't convinced of this.  Could you give an example in which you
> don't want topological ordering, possibly after discarding some pointers
> irrelevant to finalization?
 
> Hans

Our approach is more general.  Objects can be finalized in any order,
including topological order.  Can you explain why requiring objects to
be finalized _only_ in topological order is desirable?  Our implementation
is both simple and efficient, ruling out the only reasons I can think of
off hand to restrict a language feature when a more general solution is
available.

We give a few examples in our paper where finalization order can be
different from topological order.  However, even if no one ever comes
up with a real-world application that proves difficult or impossible
to write without programmer specified finalization order, the
algorithm is simple and efficient enough to use for topological-order
finalization.  With guardians the programmer has the freedom to specify
the order when necessary; with any type of collector imposed ordering,
including topological ordering, the programmer does not.

Carl