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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,147f221051e5a63d X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder3.cambrium.nl!feeder5.cambrium.nl!feeder1.cambrium.nl!feed.tweaknews.nl!news2.euro.net!newsfeed.freenet.de!npeer.de.kpn-eurorings.net!npeer-ng1.kpn.DE!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: memory management in Ada: tedious without GC? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <4ddef8bf-b5b1-4d7e-b75b-386cd6c8402c@l17g2000pri.googlegroups.com> <9f2c2db4-d6c1-4cdf-884c-5cbc26ac7701@d1g2000hsg.googlegroups.com> <1qxcw3pphdlek.1jgsfwb7atdmo.dlg@40tude.net> <48317e39$0$7550$9b4e6d93@newsspool1.arcor-online.net> Date: Mon, 19 May 2008 16:16:00 +0200 Message-ID: <4cui5l7fu3tb.1m4h2ew1xitnp$.dlg@40tude.net> NNTP-Posting-Date: 19 May 2008 16:16:00 CEST NNTP-Posting-Host: 6d743e14.newsspool2.arcor-online.net X-Trace: DXC=0D\Y6jXd=A8lIh70@7enW;^6ZC`4IXm65S@:3>?[KLCI>P On Mon, 19 May 2008 15:18:48 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov schrieb: >> On Sun, 18 May 2008 20:50:48 -0700 (PDT), Matthew Heaney wrote: >> >>> On May 16, 4:42 pm, Maciej Sobczak wrote: >>>> In Ada RAII is realized with controlled types. They are severely >>>> broken in that they are intrusive in the type hierarchy and they burn >>>> the whole budget for implementation inheritance, >>> No, this is wrong. You can add in Controlled-ness as far down the >>> hierarchy as you like, by adding a controlled component. >> >> This is broken too: >> >> 1. You don't know exactly the order in which the Finalize of the controlled >> component gets called. So if you access the container object over an >> access discriminant, that might be already invalid. > > When you design a type T, should the aspects of "death" > of an object affect the "live" aspects of T objects at all? > Death happens at a defined moment. What happens at this > moment is conceptually separate from what happens while > the object is alive, even though there are relations > between births, lives, and deaths, of course. When an object is constructed by a public or private composition of other objects, that breaks this separation. The life span of a component is longer than of the record it contains. (Exactly same problem arise upon inheritance.) Thus a component exists before the official birth and after the death of the whole. The problem is no different from dispatching upon construction/destruction. The only solution is to split construction/destruction into multiple stages, introducing class-wide constructors/destructors. Class here is "Root_Record_Component_Type'Class." So when, say, T is put into a record R, then T inherits from Root_Record_Component_Type and can attach some hook onto the constructor of the class. That constructor is a part of the constructor of R'Class. This code will be called after construction of all components of R and also after construction of R. In short, T constructed as itself and T constructed as a component of something else are not equivalent. The latter is more than the former. > But why lump together these two aspects of dynamics in the > same type? Because these are two aspects of the same thing. > Why not have types, task types perhaps, that take care > of the post mortem affairs of related types? (Other than > wasting the bits maybe.) Why switching context before running a constructor should change anything? The contradiction to the life span exists independently on that. > We have Factories. Why not have Incineration_Plants or > similar, with well defined protocols? > I certainly find it strange having to think of the > topological orderings of cleanup work when I focus on > what objects of a type should actually do (to do ==> > still alive). Because these are issues are of the types algebra you have to use in order to construct the type of the object. If you want that algebra, i.e. records, arrays, access types construction primitives, then you have to face the problem. Object doing things is miles beneath that abstraction level. It's not even typed. Types operate sets of objects. Algebra of types operates sets of types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de