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-Thread: 103376,5c89acd494ea9116 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Self pointer in limited record Date: Wed, 12 Sep 2007 16:57:05 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1183577468.034566.57830@n60g2000hse.googlegroups.com> <1188578849.187422.280620@50g2000hsm.googlegroups.com> <9fy1xoukz1e3$.h574sqmiauri$.dlg@40tude.net> <1189441670.293887.176810@g4g2000hsf.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1189634052 24833 69.95.181.76 (12 Sep 2007 21:54:12 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 12 Sep 2007 21:54:12 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Xref: g2news2.google.com comp.lang.ada:1922 Date: 2007-09-12T16:57:05-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:uffdiv96c9bc.6mn4qaig7owe.dlg@40tude.net... > On Mon, 10 Sep 2007 22:12:47 -0500, Randy Brukardt wrote: > > > "Dmitry A. Kazakov" wrote in message > > news:h9v0j8x5uuf3.puwqdmssdfn6$.dlg@40tude.net... > >> On Mon, 10 Sep 2007 16:27:50 -0000, amado.alves@gmail.com wrote: > >> > >>> FWIW, the problem was the following. I am writing a library. I wanted > >>> to provide a function to the user to allow him to specify the parent > >>> of an object in a simple way e.g. > >>> Parent_Object : Object := Lookup (Name = "foo foo"); > >>> Object : Object := Create (Name => "bla bla", Parent => > >>> Parent_Object); > >> > >> What happens when the parent gets finalized before its child? The point is > >> that if you have a reference semantics, then probably Object must be a > >> reference. So access Obkect'Class were a better design. If you want to hide > >> references, then you should use smart pointers instead. > > > > I disagree. Claw uses a design rather like the one proposed here. All of the > > needed references are created inside of the Claw library, and managed there > > (with Finalization and Adjust). For instance, if the parent object is > > finalized, the child object is finalized first (that's necessary because > > destroying a parent window also destroys any children). If a child window is > > finalized, it is unlinked from any lists that it is in. > > What happens when somebody would create some of these objects on the stack? Works fine -- that's the whole point of this design. When the objects get finalized, the Claw code for Finalize unlinks them from their parent's list of children (after destroying any children that they might have). No fuss, no muss, quite cheap to do, and no dangling pointers. > You argue for automatic collection, that is my point too. But I would go > further and hide target objects behind handles to. That would eliminate > "access." The language problem is though that there is no simple way to > delegate operations from handle to the target object. It requires a lot of > work. Not worth it, because you either lose extension or gain a second level of tagged types for no real benefit. The Claw design would be a bit more complex if you wanted the children to survive the destruction of the parent, but even that wouldn't be very hard or expensive to accomplish. You don't even need a list of root objects in order to implement this design (Claw has one for other reasons, but it is only involved in finalization to remove units from it.) The biggest annoyance in the Claw design is handling copies, and that really occurs because the Claw objects probably ought to have been limited, but we didn't want to give up aggregates and functions (and now we don't have to). Randy.