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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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!news2.google.com!postnews.google.com!j24g2000yqa.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Limited use for limited with? Date: Wed, 29 Sep 2010 01:38:40 -0700 (PDT) Organization: http://groups.google.com Message-ID: <292dd0bd-1fc4-4715-bb70-7655d0dc04eb@j24g2000yqa.googlegroups.com> 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> NNTP-Posting-Host: 137.138.182.236 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1285749520 31856 127.0.0.1 (29 Sep 2010 08:38:40 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 29 Sep 2010 08:38:40 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: j24g2000yqa.googlegroups.com; posting-host=137.138.182.236; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8,gzip(gfe) Xref: g2news1.google.com comp.lang.ada:14311 Date: 2010-09-29T01:38:40-07:00 List-Id: 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. > > 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 > =A0 =A0X : Object :=3D 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. 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. > > 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: > > =A0 =A0procedure 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. And if it performs deep-copy of X, then it breaks the association with original object. > >> 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. This is the case where pointers seem to be necessary even though nothing was allocated dynamically. And that's why we are talking "access all" here. > But even with this design you don't necessarily need public pointers. You > use handles to objects encapsulating private pointers to privately define= d > object types. [...] > =A0 =A0 =A0 Interface > =A0 =A0 =A0 =A0 / =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0 \ > Handle ---> Object Sure, but: - it does not solve the problem, it only changes an explicit problem into a wrapped problem - this is exactly what I meant when I said that in more involved scenario I have to create additional and artificial packages - they don't correspond to any system design entity 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. -- Maciej Sobczak * http://www.inspirel.com