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

[Charles Fiterman]

>This is hardly a bogus assumption, and it is not solely a result
>of C++ quirks (though it is reasonable to make the default assumption
>that anything inherited from C++ is bogus).  In my view of the world,
>if anything referred to by a finalized object may or may not be in
>some weird state (because it, too, was finalized) then it is difficult
>to regard that object as having "added value".  (If you disagree with
>this assumption of mine, then the rest of my argument makes little
>sense, but I will continue).  

This is a brand new ... TODAY ... generalization about the usefulness
of finalizers in OO, so prepare for a shift in thinking. A finalizer
is simply a function called when the collector detects an object is
unreachable from the roots. It should NOT violate the objects invariants
and leave it in a bogus state. A closed file object isn't bogus, its
semantics simply say raise an exception if sombody tries to write to
you and those are very good semantics.

Imagine a simple list of objects, each object has a finalizer that
uses the next object on the list to add to a total if there is a
next object. The list gets finalized from the tail first. The finalizers
add to the usefulness of objects in a perfectly orderly way.

>So, in order to ensure that things
>referenced by a finalizer have not yet been finalized, the finalizer
>ordering problem reappears.  The question of what to do about finalizable
>cycles reappears (rare in Cedar, people at Xerox assert, but unclear
>whether that will be true in Java, where every object inherits a finalizer,
>though the default is trivial).  To run finalizes in order and avoid
>finalizing a resurrected object, the garbage collector either finalizes
>very slowly, or employs write-barriers to detect resurrection.  Given
>the costs of the generality that you advocate, I find that I am very
>comfortable with Java's more limited approach to finalization.

Again what ever problems there are in deciding finalizer order they belong
in the mutator not the collector.

			-  
Charles Fiterman		Geodesic Systems
414 North Orleans Suite 410	Phone 312 832 1221 x223
Chicago IL 60610-4418		FAX   312 832 1230
				http://www.geodesic.com

A computer language without garbage collection
  is like a city without garbage collection.