Re[2]: [gclist] Finalization and object orientation.

[Colvin, Greg]

>Most real systems that I am familiar with use finalization 
>as the cleanup-of-last-resort.  So, for example, Smalltalk 
>will close a window if the corresponding object gets GC'd 
>but the normal usage is to close the window yourself
>when you know you're done with it.  It seems quite a 
>stretch to argue that the close method somehow breaks 
>encapsulation.

Windows are of course a user interface element, and 
typically get closed because the user did domething to close 
them, so having a close method does not break encapsualtion. 
But a closed window is not a destroyed window, and I would 
argue that a destroy method does break encapsulation.  But 
of course you don't need GC for windows: every window but 
one has a parent, no window's lifetime can exceed that of 
its parent, and the windowing system takes care of 
destroying windows itself.
     
>Finalization in Java is indeed poorly specified.  If I had 
>speculate at the reasons for this, my hunch would be to allow 
>normal process-level cleanup to handle everything (if so 
>desired by the VM implementer) rather than delaying process 
>termination while a bunch of (redundant) finalizers are run.

File handles seem to be the kind of resource that a finalizer 
is handy for: they have no owner but the process, they are 
easily encapsulated in a class, and it can be hard to know 
statically when the last user of file is gone.  But they are 
also hard to write a finalizer for: they can be a scarce 
resource, the system doesn't know that when you run out you 
should do a gc and finalize sweep, and they often wind up in 
circular relationships with buffers.  I recall a popular 
Scheme implementation in which a request to open a file would 
fail, but then succeed because a gc was done each time around 
the main loop of the interpreter.

It might be best if common OS resources were better known to 
the language runtime itself, so that you wouldn't need to 
write finalizers to deal with them.

>Scott Meyer

Greg Colvin
greg@imrgold.com