From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.ada
Subject: Re: Garbage Collection
Message-ID: <4159@enea.se>
Date: 13 Dec 88 20:07:35 GMT
Organization: ENEA DATA AB, Sweden
List-Id: <comp.lang.ada>

Bill Wolfe (wtwolfe@hubcap.clemson.edu) refuses to see the point with
garbage collection:
>   "Repeatedly" write sophisticated ADT deallocate routines??  The basic 
>   idea is to write an ADT once and use it forever (i.e., until the next 
>   language modification :-) ); where does "repeatedly" come in?

But you have to write the same boring code for every ADT you implement!
That was what ron@inmet was talking about.

>   Also, I disagree with the claim that a lot of effort is involved;
>   in my experience, DESTROY routines are among the easiest to code.
>   Usually, the ADT is defined recursively, lending itself to a very
>   easy recursive destruction procedure; after that, just destroy
>...

If it is just as easy as that. Let's say that you write a package for
double-linked lists. You provide a procedure for taking an element
out of a list. Should you free the memory allocated? You don't know
because the caller may or may not still keep an reference to the
element. He may be totally uninterested in it, but he may also want
to insert it in another list.  
  So you end up providing another procedure for deallocating the element,
which the user must to remember to call, unless he wants his memory
resources run low.
  And same goes for every ADT you define. You must provide a deallocation
routine that the user must remember to call. What worse is, the user  
may notice if he omits the call, because the implementation of the 
ADT is a static type, and the deallocation is void. And when he is
ready with his tests, you change the implementation, and his program
blows the memory.

Although you refuse to see it, garbage collection saves the programming
community from a lot of headache and true object-oriented programming
would be impossible without it.



-- 
Erland Sommarskog
ENEA Data, Stockholm
sommar@enea.se
"Frequently, unexpected errors are entirely unpredictable" - Digital Equipment