[gclist] Finalization and object orientation.

[Charles Fiterman]

At 10:59 AM 3/28/97 -0800, you wrote:
>On Mar 28, 12:04pm, Charles Fiterman wrote:
>> While you can't guarantee running finalizers at the earliest possable
>> moment you can guarantee running them. At end of job you can sort
>> remaning finalizers in finalizer order number sequence and run them.
>> Approaching the earliest moment is a quality of implementation issue.
>>
>The problem with static finalizaton ordering is that it's hard to sort out the
>system issues.
>
>If I'm implementing a type A and type A objects refer to type B objects during
>finalization, type A needs to know type Bs finalization order sequence number.
> The programmer needs to remember finalization order dependencies in order to
>get this right.  And getting it wrong in the presence of native methods is
>likely to result in memory smashes.

I am considering the following scheme. Objects have an int getFinalizerOrder()
and a void setFinalizerOrder(int n) method.

If you need a pre-finalized version of object X you use
  setFinalizerOrder(X->getFinalizerOrder() + 1);
which would be abbreviated
  finalizeBefore(X);
If you need a post-finalized version of object X you use
  setFinalizerOrder(X->getFinalizerOrder() - 1);
which would be abbreviated
  finalizeAfter(X);

Finalizer order numbers default to 0. Yesterday I thought the correct default
was MAX_INT. Today I realized that finalizers might add value not mearly
subtract it. What ever problems this kind of scheme has it must be the mutators
problem not the collectors. If their are cycles and hard to sort out system
issues they only become harder by handing them to 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.