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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!gatech!hubcap!billwolf From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.lang.ada Subject: Re: Keys are references, too (was Re: Garbage Collection) Message-ID: <3929@hubcap.UUCP> Date: 18 Dec 88 18:42:34 GMT References: <1407@trantor.harris-atd.com> Sender: news@hubcap.UUCP Reply-To: billwolf@hubcap.clemson.edu List-Id: >From article <1407@trantor.harris-atd.com>, by bbadger@x102c.uucp (Badger BA 64810): > Mr. Wolfe does not (here) recognize the social security number (SSN) as > another form of access mechanism. *Any* means by which a symbol can be > introduced to stand in as the ``name'' of the actual object will introduce > the ability to ``share'' the object by mentioning the name in two places. If I have an object A, and pointers to that object P1 and P2, then I have three distinct objects, none of which share structure. If I have objects B and C, such that a modification to B results also in a modification of C, then this is structural sharing. > Another key thing that Mr. Wolfe does not address is the problem of deciding > *when* to destroy an object. Sure, it's easy enough, in most cases, to write > a destruction routine, but you can't always wait until passing out of the > scope of the visibility of the ADT to clean up. This is why users can explicitly call DESTROY when the object is no longer needed. > Mr. Wolfe's database design has the > same problem: It's easy to remove the personnel record, but you may only > do so when the SSN is not referenced any more. Not true. If the SSN refers to a person who is dead, then that fact can be delivered as the database's response. If the SSN refers to a person who has been deleted from or never existed in the database, then this can be delivered as the database's response, perhaps by raising an exception. The database manager must decide how keys are to be managed, and users of those keys must follow the database manager's directives. > Leaving this decision up to the clients of the ADT, say by providing explicit > DESTROY(X) calls, just pushes this burden on the programmer of the client. If the programmer wishes to maximize space efficiency, explicit calls to DESTROY can be made when appropriate. The block exit mechanism provides a convenient mechanism by which this directive can be given implicitly but unambiguously, with precisely known timing. > It seems to me that investing a lot of serious effort to > get a really good GC algorithm built into the language would be much better > than expecting "average" programmers to correctly implement proper storage > reclamation for each ADT they'd like to use which requires memory allocation. Implementing proper storage allocation is the responsibility of the person who designs the ADT. I think average, below average, and barely-above-brain-dead programmers can all comprehend the fact that objects must be both created and destroyed; they are created upon declaration, and destroyed either by calling DESTROY or as an implicit consequence of block exit. > Even if not every compiler vender has ``the world's best'' memory reclamation, > it will be easier to select one that does, based on professional reviews, > than to implement it yourself. OK, all those who think it's just TERRIBLE to have to actually program for reuseability can *purchase* generic ADTs, a/k/a software components. Then you can select the components you need, based on professional reviews, rather than implementing them yourself. (Satisfied?) Wizard Software and Lib Systems are two vendors which supply such ADTs; anyone considering such a purchase should seek out professional reviews, since I write my own ADTs and therefore I have absolutely no experience with and do not in any way endorse either firm's products. I might add that Jean Ichbiah explicitly predicted, long ago, the emergence of a software components industry, based upon the generic features of the (then-new) Ada language. Slowly but surely, his prediction is being fulfilled. Bill Wolfe wtwolfe@hubcap.clemson.edu