[gclist] Finalization and object orientation.

[Charles Fiterman]

At 04:05 PM 3/27/97 -0800, you wrote:
>At 03:28 PM 3/27/97 -0600, Charles Fiterman wrote:
>
>>Saying that things that must happen shouldn't be in 
>>finalizers is deeply destructive to object orientation
>>and only makes sense if there was no way to do it right.
>
>Hmm... OO (and dynamic languages in general) seems to
>have flourished for many years without finalization or
>weak references.

Languages like Eiffel simply don't have finalizers.

Factory methods are becoming a common idom in OO. Instead
of saying I want a sparce matrix you say how many elements,
what percent you expect full and maybe your position on
speed vs space tradeoffs. The factory gives you an object
that does what you need. A common form of factory is the
object broker.

Now that method being asked for a large matrix may decide
to give you something that uses a file for overflow. In
this case it needs a finalizer. Having the finalizer apparent
to the user breaks encapsulation.

The fact that OO has lived for years without ignores the 
progress and changes in OO. Many languages compile to
continuations. One way of describing this is to say execution
frames are full objects. Now try-catch blocks are finalizers.
Surly catching exceptions can't be optional.

>Most real systems that I am familiar with use finalization
>as the cleanup-of-last-resort.  So, for example, Smalltalk
>will close a window if the corresponding object gets GC'd
>but the normal usage is to close the window yourself
>when you know you're done with it.  It seems quite a stretch
>to argue that the close method somehow breaks encapsulation.

The user of the object with the window might not be aware that
the window was there. The user might have asked for a string
not having a way to know that a window would be opened to get
that string. Forcing him to know breaks encapsulation deeply.

>Finalization in Java is indeed poorly specified.  If I had
>speculate at the reasons for this, my hunch would be to allow
>normal process-level cleanup to handle everything (if so
>desired by the VM implementer) rather than delaying process
>termination while a bunch of (redundant) finalizers are run.

I am learning via various sources that the normal implementation
of Java finalizers is the bit bucket.
			-  
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.