[gclist] Destructor FAQ

[Charles Fiterman]

> True.  I guess in a sense we're saying the same thing.  If you allow me
> to have heap-based cyclic structures containing finalizers, I probably
> won't use that feature much, precisely because it makes the timing of
> finalization so unpredictable.  But I don't see how this implies that
> one needs an elaborate set of rules *preventing* such uses.

In modern languages like ML most code is produced by functional composition.
So you can take code that looks good, and apply rules and get buggy
code unless things like strong typing are in the rules. Also you can
run code that comes from elsewhere JAVA like.

Suppose we build a class by using other classes as parents and members.
If one of those classes has finalizers we have finalizers like it or
not. We can easily end up with cyclic finalizers without intending
it or realizing the possibility. And the timing of finalization is
not unpredictable, finalization never happens thats very predictible.

So the rules must prevent it. But there is a lot of tuning here.
Some objects may be usable after finalization, some finalization may
really be optional. If A points to B and B points back but has optional
finalization there is a simple way to break the cycle don't finalize B.
Further some finalization may not need to be prompt. This sounds like
a job for a reflexive language like CLOS. Buring it in the efficiency
driven low level code of the garbage collector is bad encapsulation.