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-19 11:05:59 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!uunet!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: 19 Oct 1994 16:19:33 GMT Organization: IBM T.J. Watson Research Center Distribution: world Message-ID: <383gul$12ip@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> Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: rios8.watson.ibm.com Date: 1994-10-19T16:19:33+00:00 List-Id: In article <3816h5$n3g@schonberg.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) writes: |> One thing that should be emphasized about child packages (since some of |> the posts of this thread have not been clear on this point) is that |> child packages in no way change their parents. If you have a parent A, |> and a child A.B, then if A.B does horrible things to the abstractions |> in A, it still does not affect anyone who with's only package A. It is |> only if package A.B is with'ed that the effects of the child are |> noticable. On the other hand, a part of a large program that with's A.B can do harm that will affect parts of the program that with only A. For example: package Fractions is type Fraction_Type is private; ... private type Fraction_Type is record Numerator : Integer; Denominator : Positive; end record; -- Representation invariant: -- for X in Fraction_Type, X.Numerator and X.Denominator must -- be relatively prime. -- All the operations exported by this package that construct -- Fraction_Type values preserve this invariant, and the -- implementation of "=" depends on it. end Fractions; function Fractions.Invalid_Fraction (Numerator, Denominator: in Integer) return Fraction_Type is begin return (2*Numerator, 2*Denominator); end Fractions.Invalid_Fraction; A part of the program with'ing Fractions.Invalid_Fraction could place the value returned by that function in some global data structure. Another part of the program that with's only Fractions could fail upon trying to apply the operations of package Fractions to that value. (In practice, of course, a "problem child" would be more subtle than this one, and would presumably do its harm unintentionally.) -- Norman H. Cohen ncohen@watson.ibm.com