[gclist] Finalization and object orientation.

[Scott Meyer]

At 03:28 PM 3/27/97 -0600, Charles Fiterman wrote:

>Saying that things that must happen shouldn't be in 
>finalizers is deeply destructive to object orientation
>and only makes sense if there was no way to do it right.

Hmm... OO (and dynamic languages in general) seems to
have flourished for many years without finalization or
weak references.

If finalization is tied to automatic storage management
and the point of ASM is to enable _indefinite_ object
extent, then it seems like trying to apply finalization
to side-effects with _definite_ extents (open files, windows,
flashing lights on the keyboard) is a loosing proposition.

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.

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.

Scott Meyer                                   415 506 0987
Principal MTS                                 mailto:smeyer@us.oracle.com
Oracle - Languages & Relational Technology    standard disclaimer