[gclist] Some different thinking on finalizers.

[David Chase]

I must admit that I am still puzzled by this insistence that finalizers 
run promptly.  I think it is a request that cannot easily be granted, 
that warps the rest of the system, and that is not necessary anyway.  
I also wonder if this is an artifact of too much use of C++. 

The reason I say this is that I recently did some non-play programming 
in a language with non-prompt GC-finalization, but that also had 
TRY-FINALLY-END blocks.  The application was a limited-purpose web 
server -- it accepts *CODE* from the net, compiles it, and runs it, 
all for demonstration purposes. We care about security and audits, 
and we care about not crashing, because the people on the other end 
are potential customers, except for the ones that want to try to 
break in for "fun".

So, what about that object finalization?  I never even thought about 
it.  It never ever occurred to me to worry about it.  However, the 
code is crammed full of TRY...EXCEPT...END and TRY...FINALLY...END, 
and This Is A Good Thing.  It's explicit, it's documented, and the 
compiler can check some of it for me.  (If your favorite language
lacks try-finally-end and forces you to rely on object finalization,
maybe you're using the wrong language.  Garbage collection does not
exist in a vacuum -- the rest of the language matters, too.)

The thought of implicit finalization gives me the willies -- I want 
to see, right there, what is guaranteed to happen, and in what order.

Waht's the difference between this and GC?  GC concerns resources, 
this concerns external behavior.  I want my external behavior to 
be well-specified.  If it depends on artifacts of the garbage collector 
or the compiler (does it do tail-call elimination, or not, does it 
null out dead variables, or not?) then I'm an unhappy camper.  And
yes, you could "require" this of garbage collection, but I think 
I'd be unhappy with the resulting garbage collection.

speaking for myself,

David Chase