Re: GC with finalisation?

[Markus Mottl <mottl@miss.wu-wien.ac.at>]

> On the other hand, I consider that finalized objects supported by the
> language (such as provided by Java & Python) are a mistake. In my
> opinion, finalized objects should not have a user-provided finalizer,
> but should only deal with system resources (file descriptors, X11
> windows, coded only in C)

I once asked for finalizers (for objects) in this list, but I was pointed
to problems which I hadn't thought about: for example, user defined
finalizers might place the object to be reclaimed in a (global) reference
again - what is the garbage collector supposed to do in such cases?
Other kinds of side effects (eg. calling methods of other objects)
could lead to similar problems.

Another argument against finalization is the following: if your program
enters a very time-consuming loop in which it doesn't allocate anything,
the garbage collector will not be called and the finalization of
values/objects might be delayed for a long time.

Actually, this is even a problem in languages with stack allocated values:
as long as the value is not out of scope, the destructor will not be
called (unless the compiler manages to see that the object can be safely
finalized and deallocated earlier - which is probably more than tough).

Concurrent environments (eg. when doing network communication) may be
adversly effected by such delays.

Developers of libraries have no control about this, because this problem
depends on the way the programmer makes use of values/objects.

There are other means to "finalize" values: instead of using
destructors/finalizers, you could provide for higher-order functions
that do the job.

Eg. you want that a network connection is opened, used in some way and
closed again (but immediately!). This could look as follows:

let do_connection f =
  let con = open_connection (...) in
  f con;
  close_connection con

If you provide only such functions to the user, he doesn't have to care
about closing connections or do some other finalization and he still
has the guarantee that connections are closed immediately - which might
allow the server on the other side of the connection to do something
more useful than wait...

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl