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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ce0900b60ca3f616 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-08 13:51:34 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!ppp-2-11.cvx2.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Better Finalisation [List container strawman] Date: Thu, 8 Nov 2001 18:53:05 -0000 Message-ID: <9seup3$12h0ar$2@ID-25716.news.dfncis.de> References: <9rti6v$hcu$1@news.huji.ac.il> <9sdnb2$dd4$1@news.huji.ac.il> NNTP-Posting-Host: ppp-2-11.cvx2.telinco.net (212.1.141.11) X-Trace: fu-berlin.de 1005256291 36208987 212.1.141.11 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:16098 Date: 2001-11-08T18:53:05+00:00 List-Id: "Ehud Lamm" wrote in message news:9sdnb2$dd4$1@news.huji.ac.il... > ... > Are we coming to the conclusion that Ada95 approaches to memory management > (Controlled and storage pools), simply aren't enough for creating reliable > components, without imposing inessential restrictions? > We want user created abstractions to be as much like language supplied types > as possible, remember. I am of this conclusion, as regards finalisation. It's not a criticism of the designers of Ada 95: it's so very easy to be wise when you have the benefit of hindsight, and I think we'd all agree that overall those designers did a superb job. However, it seems feasible to me to introduce a new finalisation mechanism in the next revision. All we really need (am I wrong?) is three attributes, applying to any type T, which are the procedures carried out whenever an object of the type is created, copied, and destroyed: procedure T'Construct (Object: in out T); procedure T'Destroy (Object: in out T); procedure T'Assign (Source, Target: in out T); These attributes would, naturally, have implementation-supplied defaults, but could be overidden by attribute definition clauses, as normal. Obviously Assign would not apply to a limited type. It would probably be best if none applied to a task or protected type. The exact details of when these procedures were called, etc., would be quite complex, but I think this is essentially all we need. As for storage pools, I think the existing design is fine. I would like to see the addition (in the next language revision) of a package declaring a type, derived from Root_Storage_Pool, which had extra operations better supporting full garbage collection. I posted something (maybe a little premature) about this a while back; perhaps I'll write a paper on the subject, or something. -- Nick Roberts