[gclist] Timeliness of finalization
Mon, 31 Mar 1997 07:21:16 -0600
At 06:10 PM 3/28/97 -0800, you wrote:
>CF> Finalizers must be "sure" to protect encapsulation.
>HB> If you mean that they should run at process exit, then I disagree. Most
>HB> resources should be released by the OS...
>HB> you typically do not want to explicitly release resources that
>HB> will be released by the OS, since the OS can typically perform the operation
>HB> more cheaply.
You are assuming finalizers are restricted to releasing resourses that
will be released anyway at end of program or end of task. This assumption
cripples a very powerful general facility. We have the oppurtunity here
to vastly increase the power and flexability of language.
Finalizers are a great way to say if I do A I must do B. They improve the
ability to prove things about programs. Since collectors tend to do their
work in idle time they allow programmers to scheduele work for idle time.
I love my example of using finalizers to put lines on a report or to do
caluclations for other finalized objects. But even if you make the mistake of
restricting finalizers to freeing resources you run into serious trouble.
One of my favorite classes is multi precision integers. Mine will only
allocate 64K for an integer which is never a problem for me. But some users
find this a serious drawback. Imagine that this class knew how to use files
for overflow on very large integers. Now things like long lists and cyclic
data structures become common and the user is suddenly drawn from focusing
her attention on the problem to focusing it on the problems of finalizers.
This is terrable encapsulation. Whether an object has a finalizer should not
be the business of anything but the class description.
Again a finalizer is not a monster that leaves an object in some bogus state,
its simply another method which may make state changes or may not. If an object
uses another object and requires it to be in some special state that becomes
the user's problem whether that special state is produced by finalizers, broken
by finalizers or produced and broken by other methods.
Charles Fiterman Geodesic Systems
414 North Orleans Suite 410 Phone 312 832 1221 x223
Chicago IL 60610-4418 FAX 312 832 1230
A computer language without garbage collection
is like a city without garbage collection.