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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.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: Prologue and epilogue aspects Date: Tue, 30 Jan 2018 16:02:45 -0600 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Tue, 30 Jan 2018 22:02:46 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="22536"; 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:50213 Date: 2018-01-30T16:02:45-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:p4pah6$1gan$1@gioia.aioe.org... > On 30/01/2018 00:08, Randy Brukardt wrote: >> You mean sort of like "universal_controlled"? > > No, that would require a common base for old Ada.Finalization.Controlled > and new Controlled_Interface. no that this is undesired, but it was > rejected already. So the idea is an anonymous base, with the name nobody > dare to call. (:-)) > >> As previously noted, that >> might work for streams (and maybe pools),but controlled usually carries >> components along as well, so an interface (which cannot have components) >> is >> a bad match. > > That is an implementation detail. There is no components officially, so it > is up to the compiler designer to stuck these somewhere and take care of > the cases when both Ada.Finalization.Controlled and Controlled_Interface > are inherited from. Right, but implementing "implicit components" this way is the same work as supporting full multiple inheritance -- the components couldn't be at a fixed location in the object and you would have to use dispatching or something similar to find them. If you're going to implement that sort of thing, it would be criminal not to support it generally for all types -- and then you don't need a Controlled_Interface at all (or any other interface, for that matter). Interfaces keep the runtime cost of multiple inheritance to solely dynamic dispatching. Pretty much everything else works the same as it always did, without other overhead. But if you are going to support general multiple inheritance -- implicit or explicit -- it has a distributed cost that makes all component accesses slower (at least, anything that could be used in multiple inheritance). > BTW, I am not a fan of keeping lists of controlled objects and the rules > to finalize objects implicitly. IMO it is a misfeature which adds no > safety, just overhead. If Controlled_Interface would drop these rules I > would be only happy. Then Controlled_Interface could be an interface > without messy postmortem finalization rules, which would apply only if > Ada.Finalization.Controlled inherited. Huh? If there is no implicit finalization, then there is no need for controlled types at all, as they serve no purpose. (If you want to explicitly finalize things, you can define any subprogram for that purpose. You could even call it "Finalize". And if you want an interface like that, write it yourself.) The only reason that there is a predefined type is to get the "magic" behavior. And that behavior is designed so that every object gets finalized. An abstraction that only finalizes when it is convinient is not interesting in an Ada context - it would be riddled with holes and composition would scary. Randy.