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,c08a7609345f4e5 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Limited use for limited with? Date: Tue, 5 Oct 2010 02:25:08 -0500 Organization: Jacob Sparre Andersen Message-ID: References: <853314bc-0f79-435f-86a5-d7bcdd610731@c10g2000yqh.googlegroups.com> <36e886fa-b272-461f-bf86-a6b18366b64f@i5g2000yqe.googlegroups.com> <1eug9v5h5mf8d$.ud00hrz48lyr.dlg@40tude.net> <67044906-dacc-4526-b3f6-27e5323ab8fc@n3g2000yqb.googlegroups.com> <12chb4kbqt9ln$.zumsv1z9hqvk$.dlg@40tude.net> <292dd0bd-1fc4-4715-bb70-7655d0dc04eb@j24g2000yqa.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1286263511 4606 69.95.181.76 (5 Oct 2010 07:25:11 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 5 Oct 2010 07:25:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-RFC2646: Format=Flowed; Original Xref: g2news1.google.com comp.lang.ada:14387 Date: 2010-10-05T02:25:08-05:00 List-Id: "Maciej Sobczak" wrote in message news:292dd0bd-1fc4-4715-bb70-7655d0dc04eb@j24g2000yqa.googlegroups.com... On 29 Wrz, 09:51, "Dmitry A. Kazakov" wrote: >> No, that makes it (the public interface) more clear. Pointer is an >> implementation detail to be hidden. > >Reference leak is not an implementation detail, it is a very important >part of the contract. Dmitry is right, the *reference* ought to be part of the object, so a leak is impossible. In any case, using an access type in the specification of Register doesn't do anything to say how long the access will be used for, so that doesn't help any. (C and C++ interfaces are notorious for this problem: there is often no way to tell whether the access needs to remain valid until some later time, nor what time that is.) >No way. There are *many* Registers, meaning that a single object can >be registered in several registries, not just one. Will you suggest >passing an array of registries to the constructor? I hope not. This sounds like chaos, not a design. There is no way to figure out anything that happens with callbacks, registered or not. Callbacks are dubious to begin with; moreover, when objects need to be registered that should only happen with a very small number of places (hopefully one). Note that Claw uses exactly the design that Dmitry is describing. Each Window can be linked into a handful of data structures -- but we use Finalize to ensure it is not linked on any when the object is destroyed. The alternative of making all of this the client's problem is simply not "the Ada way". (It also would have made Claw technical support impossible; we had plenty of bizarre problems even with all of the automatic cleanup, some because compiler bugs didn't always clean things up. Without that cleanup, it would have been total chaos -- it is viritually impossible to manually clean up objects when exceptions happen [some are always missed] -- and exceptions are *always* happening in an Ada program [especially during testing].) >The problem with your approach is that it tries to bend the design of >the system in order to work around some language limitation. I prefer >having it the other way round. The "design" sounds more like copying bad ideas from some other implementation for some other programming language. >In short, I still don't see a plausible solution to my problem and >from all poor solutions that I'm aware of, the one I already use seems >to be the simplest. When you start with a poor design, it's not surprising you can only find poor solutions... Randy.