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,c08a7609345f4e5 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news4.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.71.MISMATCH!xlned.com!feeder3.xlned.com!feeder.erje.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Limited use for limited with? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> Date: Wed, 29 Sep 2010 11:16:42 +0200 Message-ID: <1ffdzc3fkapks$.15g452pvvgrem$.dlg@40tude.net> NNTP-Posting-Date: 29 Sep 2010 11:16:42 CEST NNTP-Posting-Host: 49b867c9.newsspool4.arcor-online.net X-Trace: DXC=:2BD`a5>CiP5TOT9_N5ihXT X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:14312 Date: 2010-09-29T11:16:42+02:00 List-Id: On Wed, 29 Sep 2010 01:38:40 -0700 (PDT), Maciej Sobczak wrote: > On 29 Wrz, 09:51, "Dmitry A. Kazakov" > wrote: > >>> There are still access types. The fact that they are not explicitly >>> seen in operation signatures just makes it more obscure. >> >> 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. It does not leak. >>> No way. There are many Registers and it's up to the user to decide >>> where the given object should be registered; constructor has no such >>> knowledge. >> >> He decides that upon construction: >> >> declare >> � �X : Object := Create (My_Repository); > > 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. If that is the object's property to be registered in multiple lists, e.g. when the list is static, then yes. Otherwise you register it dynamically. >>> And *when* it should be registered, which is not necessarily at >>> construction time. >> >> A good design rule is that all objects are usable at each point of its >> existence. But if unregistered object are OK, then provide a Register >> operation: >> >> � �procedure Register (X : in out Object, Y : in out Repository'Class); > > And we are back to the beginning. If this uses pointers internally, > then the reference leak is not expressed in the signature. It is > inherently unsafe. I see no unsafety. References are maintained by the object itself. It is the safest possible way. [I presume that the scope of the list heads encloses ones of the objects.] > And if it performs deep-copy of X, then it breaks the association with > original object. No it does not. Object is a limited type. >>>> I tend to avoid "all" everywhere I can. >> >>> Apparently here I cannot. >> >> Because you have a model in mind, which treats objects as dynamically >> allocated entities. > > Not at all. In practice all these objects will be created at library > level or as locals in subprograms (perhaps in the main procedure). No > dynamic memory is needed here, but the ability for objects to refer > each other is still essential. OK, that would be a directed graph. Graphs are doable, but difficult without pointers, fortunately graphs are very rarely needed. > 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. You didn't state it yet. The point is that it is a good advise not to expose both referential types and the object types in public interfaces. You do either of them and hide another. If that is impossible in some particular cases, that is an Ada problem, which is better to address, rather than keep on mounting language kludges, which "limited with" possibly is, IMO. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de