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.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3498dd887729ed19
X-Google-Attributes: gid103376,public
From: rogoff@sccm.Stanford.EDU (Brian Rogoff)
Subject: Re: Garbage Collection in Ada
Date: 1996/10/30
Message-ID: <ROGOFF.96Oct30092113@sccm.Stanford.EDU>#1/1
X-Deja-AN: 193232234
references: <199610181934142408603@dialup101-3-15.swipnet.se>
organization: /u/rogoff/.organization
reply-to: rogoff@sccm.stanford.edu
newsgroups: comp.lang.ada
Date: 1996-10-30T00:00:00+00:00
List-Id: <comp.lang.ada>


jsa@alexandria (Jon S Anthony) writes:
   Richard Riehle <rriehle@nunic.nu.edu> writes:
   > While it is true that Root_Storage_Pool is derived
   > from Ada.Finalization.Limited_Controlled, this should not be
   > a particular hardship when control over the storage pool,
   > and automatic garbage collection are essential to a given design.

   The keys are being able to

   a) tie an access type to a pool
   b) define a type which cannot be allocated except by user defined 
      constructor (limited type with unknown discriminants).  This 
      gurantees that a) is the only access type a client can use for the type.

   c) ability to redefine _new_ for the pool

   to a much lesser extent: 

   d) ability to redefine manual deallocation for pool.

   Finalization for the pool could also be useful (though only in special
   cases)

I mentioned that the ODMG Ada 95 binding paper, which I can no longer find on 
the web, had a discussion of storage pools, and suggested that a very similar 
feature be designed which was like Storage_Pools except that it supported 
user definable dereferencing and rereferencing of access types. This was 
used for persistence and GC.

-- Brian