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 14:31:01 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!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: <7GfWa.5186$mv6.907516@news20.bellglobal.com> Date: Thu, 31 Jul 2003 17:15:54 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1059686147 198.96.223.163 (Thu, 31 Jul 2003 17:15:47 EDT) NNTP-Posting-Date: Thu, 31 Jul 2003 17:15:47 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:41109 Date: 2003-07-31T17:15:54-04:00 List-Id: Randy Brukardt wrote: > "Warren W. Gay VE3WWG" wrote in message > news:AVbWa.1379$qN3.184689@news20.bellglobal.com... > >>>But if you do not want to see private things, then the package should >>>not be a child. >> >>You are missing the point. If the package is not a child package, >>then this new package loses all access to the other private >>types declared in the private section. Sometimes you need to have >>things both ways. > > That sounds like a very muddled design. Previously you said: > >>Irregardless, there is _NO_ way whatsoever to identify >>Ada95 OO members/primitives as "protected" (ie. accessable >>by derived code, but not to the end clients of the object). > > Which is false: The derived code goes in children (if they need the > visibility), the end clients do not. If your end clients are in children, > you've got design problems. I think you're mis-reading me here. I am concerned with being able to write a child package which derives a new type (object) from the parent package. Because the child package enjoys full visibility (a good thing for the parent's private types I need), this child package _ALSO_ has full visibility to the tagged objects defined in the private part of the parent (this is normally a good thing). BUT, I want, in many cases, to restrict access to members/primitives of the parent tagged type. Why is this so difficult to describe/understand? Let's use C++ terms then: Take the C++ concept of a "private" member, and apply it to a child package, but, having the child package not be able to tamper with private members (ie. these members are not public, and not protected using C++ terms). Conversely: Take a C++ class member, declare members "protected" so only deriving code has visibility; but not the end client code (application code). > What you're asking for is a fine-grained visibility control that does not > exist anywhere in Ada. YES! And precisely my point. It _does_ not exist in Ada. > Some have claimed this is a fault, but in any case you'd have a very > different language if you had those sorts of capabilities. All I ever was suggesting was that some further discussion might be worthwhile, particularly in light of 200y changes. > One of the > advantages of the current scheme is that it works very well for > programming-in-the-large: a change to a distant unit can only change units > in which it is directly referenced. I fail to see how the implementation of "protected" would change this "nature" for programming in the large. > We've found in working on "limited with" that this property is a lot harder > to maintain if you have views of the same entity with different properties > that can clash (if you have a diamond-shaped with pattern). This is a > property that we should not be willing to give up for Ada. I was never proposing, nor interested in selective uses of private parts of a package. I am only speaking of tagged record views here, but it has application to child packages, because of their special status. > Anyway, I think you will have to make a complete proposal so we can tear it > to shreds. :-) Claiming that there is some lack of visibility control > without showing how that control could be defined and would be used in > practice is not very compelling. > > Randy. Randy, I don't think you're being entirely fair about this discussion. We're talking about protected access of classes (C++). I am not saying Ada has to have it, but merely pointing out that I find it "missing" WRT to having used C++ in a previous life. IOW, I find a need/wish for it, on the principle that "information hiding" is safer, which is what Ada95 already makes good use of. Claiming that the current Ada model is without need for improvement, is IMO, a bit biased. It suggests that the current visibility model has already achieved perfection. But, if it never came to pass, I will still sleep just as well. I only made it a point of discussion. B-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg