From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,XPRIO autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Mon, 20 Sep 2021 19:45:28 -0500 Organization: JSA Research & Innovation Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Injection-Date: Tue, 21 Sep 2021 00:45:30 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="24394"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:62799 List-Id: User calls on Initialize and Finalize have no special meaning; they're igorned for the purposes of language-defined finalization. The fact that they're normal routines and can be called by someone else means that some defensive programming is needed. That all happened because of the "scope reduction" of Ada 9x; the dedicated creation/finalization mechanism got dumped. Finalization was too important to lose completely, so Tucker cooked up the current much simpler mechanism in order to avoid the objections. It's not ideal for that reason -- but Finalize would still have been a normal subprogram that anyone could call (what else could it have been -- the mechanism of stream attributes could have been used instead). I don't think there is a way that one could have prevented user-defined calls to these routines (even if they had a special name, you still could have renamed an existing subprogram to the special name). Randy. "Dmitry A. Kazakov" wrote in message news:si9gnb$926$1@gioia.aioe.org... > On 2021-09-20 10:08, Niklas Holsti wrote: >> On 2021-09-20 10:35, Dmitry A. Kazakov wrote: > >>> No. You can have them accessible over other access types with wider >>> scopes: >>> >>> Collection_Pointer := new X; >>> Global_Pointer := Collection_Pointer.all'Unchecked_Access; >>> >> So, unchecked programming, as I said. > > Right, working with pools is all that thing. Maybe "new" should be named > "unchecked_new" (:-)) > > Finalize and Initialize certainly should have been Unchecked_Finalize and > Unchecked_Initialize as they are not enforced. You can override the > parent's Initialize and never call it. It is a plain primitive operations > anybody can call any time any place. You can even call it before the > object is fully initialized! > > So, why bother with objects the user manually allocates (and forgets to > free)? > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de