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 Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!news.stack.nl!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Should weak counted reference be able to be strengthened? Date: Fri, 21 Nov 2014 17:50:38 +0100 Organization: cbb software GmbH Message-ID: References: <7d9r3whe43z8$.1f2l3n5cz0zh0$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: wfRpp7ltpEWhI2na6kgpfA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: number.nntp.giganews.com comp.lang.ada:190914 Date: 2014-11-21T17:50:38+01:00 List-Id: On Fri, 21 Nov 2014 15:00:12 +0000 (UTC), Natasha Kerensikova wrote: > The strong reference is hidden in the accessor object. Consider for > example the following specification fragments, where T is the formal > type of the referred objects: > > type Accessor (Data : not null access constant T) is limited private; > > type Strong_Reference is tagged private; > > function Query (Ref : Strong_Reference) return Accessor; > > type Weak_Reference is tagged private; > > function Weaken (Parent : Strong_Reference'Class) return Weak_Reference; > -- 'Class only because we are still in the same package > > function Query (Ref : Weak_Reference) return Accessor; > > private > > type Accessor (Data : not null access constant T) is limited record > Parent : Strong_Reference; > end record; Why do you need accessors? For Ada's crazy implicit dereference? > The only way to actually reach a referred object is by dereferencing the > access discriminant of an Accessor value. The strong reference inside > Accessor objects ensure that the referred object will outlive the > Accessor object. It is much simpler to return a plain access type: function Ptr (Ref : Strong_Reference) return not null access T['Class]; > However in that example, there is no way for the client to obtain a > strong reference from a weak one, since the one inside Accessor (that > ensures safe access) is private. I don't understand the design anyway. Strong references should be obtained from the access type the object (straight after object allocation). >>> In all the use cases I can imagine, the weak reference is only used to >>> access the referred object. I can't make up an example where a strong >>> reference would be needed from only a weak one. Am I missing something? >> >> Yes. There are many cases when weak references are components of containers >> or when weak references are used in composite objects which change their >> content upon disappearance of the referenced object. > > I wasn't aware of such a possibility, that's probably the big thing I > missed. > > In all the examples with which I came up, the owner of a weak reference > doesn't need to distinguish between an empty reference that never held > an object and an empty reference because the object has been released. A classic example is GUI. Let you have a button widget. If you put the button into a box widget, that is a strong reference held by the box widget. But if you can connect to the button's signal On_Click, this is a weak reference. If the button is deleted, the signal handler is silently disconnected. Having any signals connected does not prevent the signal emitters from being deleted. >>> The interesting point I see in forbidding such a "reference >>> strengthening" is to prevent some cases circular strong references, >>> which is the problem weak references are supposed to solve. >> >> When a weak reference is promoted to a strong one that occurs on a nested >> context. Such strong references are allocated on the stack. Therefore there >> is no any danger of getting circular dependencies unless the structure of >> references in objects is already circular. In short, there is nothing to >> worry about. > > Such strong references are not limited, and could be very well be copied > to a permanent object. That is all the point. In this case circular dependency is already in the design of the container object's types. It is irrelevant if circular components are initialized from weak or strong references. > However I agree that the strong reference inside > Accessor is indeed always on the stack, and guaranteed to never escape > from the Accessor object. Helper types is bad design. >>> As a side note, I'm a bit surprised by how easy weak/strong reference >>> seem to be: I think I would only need to store two counters instead of >>> one, one for the strong references and one for all references, >>> deallocating the object when the strong reference counter reaches >>> zero, and freeing the counters when the total counter reaches zero -- as >>> if each weak reference was a strong reference to the counters. Then it's >>> only a matter of adding an atomic increase-if-not-zero to the strong >>> reference counter to build accessors from weak references. >>> Is there a subtle trap I'm missing? >> >> Weak references usually require a notification mechanism when the object >> disappears. Thus you need a count and the head of the doubly-linked list of >> the weak references pointing to the object. > > I'm still not completely figuring out how much usefulness is lost when > the notification mechanism is not implemented. You cannot implement them without that. A weak reference must be invalidated when the object disappear. Thus some kind of notification must be there anyway. > Honestly, weak references with notifications feel like too large a > project for me. Even more complicated systems, like those you described > in the following snipped paragraph, are also out of the question. There > is only so much I feel comfortable to re-invent. Here is an implementation of: http://www.dmitry-kazakov.de/ada/components.htm#Backward_Link -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de