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-08-01 13:03:12 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Need advice re package organization. Date: Fri, 1 Aug 2003 15:04:54 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3F228F3B.9020203@attbi.com> <3F22F9E9.3040307@attbi.com> <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com> <7GfWa.5186$mv6.907516@news20.bellglobal.com> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:41132 Date: 2003-08-01T15:04:54-05:00 List-Id: "Warren W. Gay VE3WWG" wrote in message news:7GfWa.5186$mv6.907516@news20.bellglobal.com... > Randy Brukardt wrote: > > 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. Certainly possible. > 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). OK. Let me understand you. This translates to "I want to see private things". > BUT, I want, in many cases, to restrict access to members/primitives > of the parent tagged type. This translates to "I do not want to see private things." Does it make it clear why I'm confused? :-) You said that you need visibility on the parent's private types, but you clearly don't need to be a child to have that. And if you do need visibility on items in the private part, then you need that. Finally, if there is stuff that you don't want anyone to have visibility on, you put item into the body. So where's the problem? > Why is this so difficult to describe/understand? Let's use C++ terms then: Sorry, I don't know C++ well enough to understand the detailed meaning of these terms. I'd like to see an actual Ada proposal, which I can try to understand. > > 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. I don't believe that it is possible to graft fine-grained visibility control into Ada. It's been tried before (during the Ada 9x process) and it didn't work out then. It would make perfect sense for an Ada-like language to have this sort of control, but not Ada itself (because of compatibility issues). > > 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. I still have no clear idea what you have in mind. I'm leary of saying that we need fine-grained visibility control, but only of "record views" (whatever that is). Why does your problem not apply to other declarations (subprograms and subtypes) as well? > > 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, I don't think you're being entirely fair about this discussion. > > We're talking about protected access of classes (C++). As I said above, I don't know C++ well enough to know exactly what it is that you are proposing. And in any case, Ada is not C++. Please describe what you want in Ada terms, with Ada syntax. > 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. No, the visibility model is far from perfect. The problem is that it has resisted most attempts to change it, because it is very hard to come up with a compatible change that works in ALL cases. A lot of ideas make perfect sense in the normal case, but come to grief on bizarre corner cases that no one really cares about (but have to work). Having a lot of experience with that, I tend to resist making another attempt, particularly without a clear justification. That IS my bias. > But, if it never came to pass, I will still sleep just as well. I only > made it a point of discussion. B-) Well, it does not hurt to bring up ideas. I just would like to understand what they are well enough to understand why the language doesn't provide it already. Randy.