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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Prologue and epilogue aspects Date: Wed, 31 Jan 2018 16:05:46 +0100 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.2 Xref: reader02.eternal-september.org comp.lang.ada:50225 Date: 2018-01-31T16:05:46+01:00 List-Id: On 30/01/2018 23:02, Randy Brukardt wrote: > "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). There would be no components unless Ada.Finalization.Controlled inherited. When inherited from Controlled_Interface only, all checks if to call Initialize, Finalize, Adjust will be static. No lists of objects. >> 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. "Implicit" meant called upon implicit destruction, e.g. when access types go out of the scope. That thing is not needed. I don't see other reason for the Controlled_Interface to induce hidden components. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de