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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,23cf9f1e93744eed X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-31 09:54:39 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!torn!snoopy.risq.qc.ca!news.uunet.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Need advice re package organization. References: <3F228F3B.9020203@attbi.com> <3F22F9E9.3040307@attbi.com> <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <7DbWa.1370$qN3.183518@news20.bellglobal.com> Date: Thu, 31 Jul 2003 12:39:36 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1059669571 198.96.223.163 (Thu, 31 Jul 2003 12:39:31 EDT) NNTP-Posting-Date: Thu, 31 Jul 2003 12:39:31 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:41086 Date: 2003-07-31T12:39:36-04:00 List-Id: Randy Brukardt wrote: > "Warren W. Gay VE3WWG" wrote in message > news:clWVa.4191$mv6.741217@news20.bellglobal.com... > >>The problem occurs in the private child package (IMO) because >>you want to derive new objects from parent tagged records. The >>danger that develops is that the child package's body code may >>monkey with things in the parent object that you don't want it >>to (this is lack of information hiding). >> >>However, you can fix the object visibility by making it a non >>child package (just another package using the first). However, >>the problem then becomes that you lose access to other types >>and definitions that are in the other package's private part. >> >>So in my mind, there still exists a short-coming OO wise >>in the visibility rules for objects: it needs a way to >>mark parts of a tagged object as "off limits" for the child >>package, which always enjoys full visibility of the parent >>package's tagged record (object). > > You can do this by deferring the contents of the tagged type to the body: > > type My_Type_Contents; > type My_Type_Contents_Access is access all My_Type_Contents; > type My_Type is tagged record > Contents : My_Type_Contents_Access; > end record; > > Then no child can see the contents. Claw uses this technique in some cases. > The body contains the full declaration of My_Type_Contents. That appears to accomplish the end result. However, this design pays a price in allocating and freeing an additional [sub]object. For some designs this would be acceptable, but not where you have many instances of the object, where the price of allocate/free is too heavy. So I think my point still stands: you really cannot "properly" accomplish what I have set out to do, although you have illustrated a work-around. > This technique works best when the tagged type is Controlled (since the vast > majority of tagged types ought to be controlled, this is not a real > restriction). Then the Initialize routine can allocate the contents, and the > Finalize can free it. The only remaining danger would be someone assigning a > Null into the Contents access, which is a lot less likely than fiddling with > components. > > Randy. Agreed that the risk is lower, but it still exists if you place the objects (from a library) in the hands of a user. If you are supporting that library, this increases risk of servicing calls that should not be your responsibility. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg