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 10:12:40 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!snoopy.risq.qc.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> <9d2Wa.301$jp.253@newsread4.news.pas.earthlink.net> In-Reply-To: <9d2Wa.301$jp.253@newsread4.news.pas.earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 31 Jul 2003 12:57:33 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1059670648 198.96.223.163 (Thu, 31 Jul 2003 12:57:28 EDT) NNTP-Posting-Date: Thu, 31 Jul 2003 12:57:28 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:41088 Date: 2003-07-31T12:57:33-04:00 List-Id: Matthew Heaney 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). > > That the private part of the parent package is visible to (the private part > of) a child is a feature of the language. Yes, I know :-) > Yes, there is a "lack of information hiding," but the syntax of the language > is designed so that it's obvious who has access to the private information, > e.g. if I see P.C, I know that C has visibility to P. How does the "obviousness" prevent developers of the body from messing up the parent object's internals? Maybe there is an accidental reference to like-named members or methods? > This is a consequence of the fact that visibility in Ada is controlled by > the module relationship. One issue in C++ is that if I have: I understand the issue, and I myself prefer Ada95 to any computer language, but folks, let's be honest about the weakness here ;-) > class B > { > public: > virtual ~B(); > protected: > secret_t m_secret; > }; > > then yes, this says that data member m_secret is visible to classes that > derive from B, but there's nothing that identifies which classes those are. > If I see a class D, there's nothing to tell me that D derives from B (unless > you look at D's declaration, of course). Of course. > This is why I usually name derived classes by tacking the derived name onto > the base class name, e,g > > class Presentation { /* ... */ }; > class PresentationAVI : public Presentation { /* ... */ }; > etc > > class Stream { /* ... */ }; > class StreamAVI : public Stream { /* ... */ }; > class StreamWAV : public Stream { /* ... */ }; > etc. Well, it works for you and that is fine. I see this as bending the language to suit your needs, and clearly C++ has a weakness in this respect. > At least in Ada, if I have one type that derives from another, e.g. > > package P is > type T is tagged ...; > .... > end P; > > package P.C is > type NT is new T with ...; > .... > end P.C; > > then at least when I see P.C.NT, I know immediately that C can see the > private part of P. Yes, but you've achieved that simplicity at the expense of functionality. Some of us would rather have the functionality as a tradeoff (and that is what we're talking about here, unless a proposed solution addresses both issues). This is the basis of much of the MI discussion. Some like the simplicity of not having it, while others insist on having the MI supported. > So I don't agree that one should that a parent package should try to "hide" > stuff from a child. You are saying you don't support it because you favour the simplicity of the approach. That is different than saying that you don't agree that information hiding here should be supported (maybe clarification of your position is required here?) But I would expect that you would still favour the use of information hiding, when it was appropriate. I would expect that if your position (simplicity) was achieved, then you would not have an objection to the point that I am raising. > The set of modules that have visibility to the private > part of P (and hence, that need to be consulted if there is a change) is > bounded, and clearly demarcated. In the typical case the members of a > package hierarchy (the "subsystem") would be kept together in a project, > probably in the same directory, and maintained by a single person. Again, you are evaluating the point on the basis of how easy things are "identified". But the real point of this discussion is that a object visibility control is lacking. PROTECTED ACCESS: In fact, the other side of the OO coin is also true: namely in Ada95, you can only have public or private members and primitives (without breaking the object into multiple derivations). At the very least, this is a pain. 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). Is this a show stopper? Well, no. But it has been long recognized in the software industry that information hiding promotes safety. All I am saying, is that Ada95 seems to lack this feature and it should perhaps be more vigorously discussed ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg