Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ginosko!rex!ukma!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.sw.components
Subject: Re: Garbage Collection
Message-ID: <6478@hubcap.clemson.edu>
Date: 16 Sep 89 20:17:00 GMT
References: <175@ntmtv.UUCP>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 31

From article <175@ntmtv.UUCP>, by hopper@ntmtv.UUCP (Ian Hopper):
> I have always felt that some form of Garbage Collection is
> needed in order to do a decent job on reusable "Collection"
> modules.  

    Actually, garbage collection is unacceptable to certain
    users, real-time users in particular.  Therefore, if one
    is designing a component for the largest possible audience,
    that component must manage its own space.  Anything less is
    going to result in a component which is essentially useless 
    when real-time software systems are being constructed.

    As far as languages go, I don't make use of GC (for the reason
    outlined above), and therefore don't care whether a language
    has GC or not.  Considerations like whether or not *secure* ADTs
    can be constructed (are limited private types available?), whether
    they can be constructed to be safe and efficient in the presence of 
    multitasking, and so on, are much more important.

    If there *is* garbage collection, whether required by a language
    or provided as a compiler feature (e.g., in Ada, where GC is an
    option that compilers are free to provide if the market wants it),
    my primary concern is that I be able to turn the damn thing off.

    Fortunately, Ada provides the pragma CONTROLLED, allowing me to
    specify that a given type is not to be touched by any garbage
    collector such that the compilers are required to obey, so there
    is room for coexistence as far as GC is concerned.


    Bill Wolfe, wtwolfe@hubcap.clemson.edu