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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.13.204.199 with SMTP id o190mr15409383ywd.39.1439127234439; Sun, 09 Aug 2015 06:33:54 -0700 (PDT) X-Received: by 10.140.91.182 with SMTP id z51mr148543qgd.5.1439127234400; Sun, 09 Aug 2015 06:33:54 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!69no4650636qgl.1!news-out.google.com!b31ni5949qge.0!nntp.google.com!z61no6014465qge.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 9 Aug 2015 06:33:54 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=85.201.165.65; posting-account=6m7axgkAAADBKh082FfZLdYsJ24CXYi5 NNTP-Posting-Host: 85.201.165.65 References: <12wxvkghwgpw3.k4qf1rqnppjb$.dlg@40tude.net> <8b424e66-337a-4943-91d1-e421312b5c95@googlegroups.com> <186o8cox1jqwa.yahqsx8p0k84$.dlg@40tude.net> <3341271b-4926-40cb-a9aa-660522d56f24@googlegroups.com> <34d1bef3-5d7b-4420-8256-7227d5792a13@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <322c2392-6b55-46e9-a8e4-97d4d8023407@googlegroups.com> Subject: Re: Design of cross referring types/classes and proper usage of containers From: Serge Robyns Injection-Date: Sun, 09 Aug 2015 13:33:54 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:27395 Date: 2015-08-09T06:33:54-07:00 List-Id: On Sunday, 9 August 2015 05:11:07 UTC+2, Randy Brukardt wrote: > I'd probably try to avoid returning an access at all; for reading purpose= s,=20 > you can just return a copy of the subscription; and for writing purposes = I'd=20 > suggest having the Subscription package do that (that is, it would contai= n=20 > some procedures for altering particular Subscriptions). >=20 > If that's too much disruption for your design, you can try going over to = the=20 > dark side and use an anonymous access return type. That will push the=20 > accessibility check to run-time; so long as the caller doesn't try to sto= re=20 > the resulting access, they ought to be able to use it just as you can use= =20 > Reference. OTOH, if they try to put into a long-lived type, Program_Error= =20 > will be raised by the return statement. In this case, you do not want the= re=20 > to be a type T_Subscription_Access, as that would encourage clients to us= e=20 > it (causing the exception). >=20 > This would look like: >=20 > function Get_Subscription > (Subscription_Name : in T_Subscription_Name) > return access T_Subscription is > Cursor : Subscription_Map.Cursor; > begin > Cursor :=3D Subscriptions.Find (Subscription_Name); > if Cursor =3D Subscription_Map.No_Element then > return null; > else > return Subscriptions.Reference (Cursor).Element; > end if; > end Get_Subscription; > This was a very precious hint. It helped me to solve the problem with some= trial and errors on the real code. I had to resolve it also for a cursor,= that behaves slightly different, as I'm also using Index, but there the RM= was for once helpful to me. Important is to declare the container aliased. And yes, I rather use an access variable for two reasons. Performance on one hand as some objects can be very large and hiding the im= plementation on the other as I plan to use two implementations through a br= idge & proxy patterns, one being in in memory XML the other a database. Th= e bridge pattern handles the options, the proxy (in case for the DB) loadin= g and unloading the data. The later means that the access variable could p= oint to a complex object with some state information. Currently, I've one p= ackage implementing the basic operations on a single subscription for examp= le and another one implementing the collection, as per above code. > You could also return the Reference_Type itself (slightly safer, as clien= ts=20 > would get a compile-time failure). But that would messy (probably you'd w= ant=20 > to make it a private type and then derive it from the Reference_Type of t= he=20 > instance). I can show you what I mean on Monday if you can't figure it ou= t=20 > yourself (I'll have to code up something to see if it actually works). As explained, this seems not to suit my current needs, maybe at some point = in time I'll see the need/use for this approach. I'll keep it in mind. > In any case, the point is that if you are going to eliminate the access= =20 > types, you really need to eliminate all of them! Leaving some is=20 > problematical. I'm trying to eliminate them as much as possible and where it makes sense, = but I won't be pathological about it. >=20 > Randy. Thank you very much Randy. You saved my day and motivated me to continue t= o use Ada for my project. Moreover, I really believe that the Ada 2012 cha= nges really helps me on my project. Serge