[gclist] Finalization and object orientation.
Guillermo (Bill) J. Rozas
Tue, 1 Apr 1997 18:15:56 -0800 (PST)
| Date: 31 Mar 97 11:05:35 -0800
| From: "Giuliano Carlini" <GCARLINI@us.oracle.com>
| Subject: Re: [gclist] Finalization and object orientation.
| But, I don't think we need to handle cycles. Finalization
| order usually indicates dependence. If A is dependent on B,
| then B must finalize before A. A and B can't be both dependent
| upon one another, or there is no possible way to finalize
| them. I therefore believe that a dependence graph is
| necessarily a DAG.
Are you sure about that? Almost all cases that I have seen have the
opposite relationship, namely that if A depends on (encapsulates) B,
then A must be finalized before B.
For example, assume that we have a language/system which creates files
such that if they are not explicitly closed with a save/commit option,
they are reclaimed. I.e. the finalization (when not explicitly
closed) is "close and delete". On top of that (the basic file object
provided by the runtime library) we want to build a file object A that
has the opposite semantics, i.e. if not explicitly "aborted", "close
and save". Clearly A depends on B which is the primitive file object
in the system. On the other hand, A must finalize before B, to
prevent B from deleting it before A takes action.
However, I agree that the dependence graph is a DAG.
| I never suggested using the reference graph to determine the
| dependence graph. Explicit declaration of mutator semantics
| is the best course in my opinion.
I think this is an important point, and fits with my experience.
My experience is that you can have a "declaration" of the following
(finalize! object set-of-objects action)
where OBJECT must be finalized _before_ any of the objects in
SET-OF-OBJECTS (which may obviously be empty) by invoking
FINALIZE! constructs the dag and checks for cycles outside of the
collector. The collector then has no problem determining finalization
Of course, other declarations are useful as well.