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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a8985ede8fe3d111 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-20 07:40:18 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!newsgate.watson.ibm.com!watnews.watson.ibm.com!ncohen From: ncohen@watson.ibm.com (Norman H. Cohen) Newsgroups: comp.lang.ada Subject: Re: Child packages Date: 20 Oct 1994 14:06:50 GMT Organization: IBM T.J. Watson Research Center Distribution: world Message-ID: <385thq$kh6@watnews1.watson.ibm.com> References: <1994Oct4.090807@di.epfl.ch> <37kanl$jfd@u.cc.utah.edu> <1994Oct18.103131@di.epfl.ch> <3816h5$n3g@schonberg.cs.nyu.edu> <383h86$12ip@watnews1.watson.ibm.com> <38496c$1l1@gnat.cs.nyu.edu> Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: rios8.watson.ibm.com Date: 1994-10-20T14:06:50+00:00 List-Id: In article <38496c$1l1@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) writes: |> Norman, there is still a big difference between modifying the text of a |> package and adding a child, much to big for tantamout :-) |> |> The big difference is that if you modify the text of a package you can |> blow up existing clients of that package in different programs. |> |> If you write a child, it is completely separate, and affects on programs |> that use the child, |> |> so the level of access controls needed is quite different. a given program |> may want to lock out any additional child units, and another program may |> wish to allow them, but neither could permit the mucking with a shared |> package's text. This is true. I should have said that adding a child is tantamount to modifying a program's OWN COPY of a package. (The point is that encapsulation in a package provides no more protection against breaking an abstraction by writing a child than it does against breaking an abstraction by modifying the text of the package. Access controls CAN provide such protection, and I agree that child packages facilitate access controls with a finer granularity.) Even the comparison of a shared package with a program-specific child to a program-specific copy of the package is not quite right, of course, because a change to the shared copy is immediately reflected in each program-specific copy. Some changes to a shared parent may invalidate assumptions on which children depended, thus breaking program-specific virtual copies of the package. However, others may not. For example, if a bug is found in the body of a subprogram provided by the parent, causing the subprogram to violate its specifications in obscure cases, a fix to the parent package immediately fixes the bug in all programs that use the package or its children. (If a program exploited the bug as a "feature", the bug fix will break that program, but given my hypothesis that the bug violated the subprogram's specifications, the fault in that case lies with the program.) The issue of maintaining a parent package shared by multiple programs brings out a serious drawback of child units. One of the breakthroughs provided by Ada 83 was the separation of a module into distinct textual regions defining a module's interface (the package visible part) and its implementation (the private part and body). In languages not providing this clear textual distinction, it is common to speak of "documented features" and "undocumented features" rather than properties of the interface and properties of the implementation. In Ada 83, the maintainer of a package always had complete freedom to change the details of the implementation. (Caveat unchecked-convertor.) In Ada 94 there is a third category of features. Between the interface that may be exploited by clients and the implementation details that the parent-package maintainer reserves the right to change, there is a set of IMPLEMENTATION features that the package maintainer agrees to leave unchanged, in the expectation that child units may exploit these features. (This distinction is analogous to the C++ public/protected/private trichotomy.) Unfortunately, the distinction between "private" implementation details (which even children should not exploit) and "protected" implementation details (hidden from ordinary clients but part of the interface as far as child units are concerned) is not reflected in any way in the text of a parent package, except of course in comments. Thus we are back to distinguishing between "documented features" of a package implementation and "undocumented features". (We would like to hope that the so-called "undocumented features" are actually clearly DOCUMENTED, in comments, as not to be relied on by child units!) While child packages provide many more advantages than disadvantages, I feel we have lost something important from Ada 83--a clearly marked, compiler-recognized distinction between those aspects of a module that do and do not form a part of its "contract". -- Norman H. Cohen ncohen@watson.ibm.com