[gclist] Destructor FAQ

[Charles Fiterman]

> "I don't see any harm in letting a finalizer see an
> already-finalized object -- if the programmer has cycles, then the
> finalizer has to be written to take that into account.  A finalized
> object is still in a well-defined state (maybe it has some nil pointers
> in it) -- pointing to an already-finalized object is not a disaster like
> a dangling pointer is."

Here I don`t see how an already finalized object has a usable state.
A finalized file object is closed. That may be well defined but
using it is a problem. Perhaps we could distinguish between finalized
objects left in a usable state and those left in a useless state.
This would allow simplification of finalization dependencies for
the former but not the later.

But cleanly separating finalizers from collection solves so many
problems. The finalize engine will attempt to finalize one object
at a time and in a well defined order simplifing debugging. If a
finalizer wants to modify the finalize graph by the rules, no problem.
It can even put itself back on the graph. No messy zeroing some
pointers.

What I`m proposing is makeing finalization a high level notion in
a CLOS like reflexive language. You would have commands to attach
finalizers to various objects including execution frames. Defining
a finalizer for a function would mean when its execution frame was
built a finalizer would be attached automatically. Defining a destructor
for a class would mean that when it was instantiated a finalizer would
be attached to the object.