Re: Self pointer in limited record

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:uffdiv96c9bc.6mn4qaig7owe.dlg@40tude.net...
> On Mon, 10 Sep 2007 22:12:47 -0500, Randy Brukardt wrote:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.