Re: Child packages

[ncohen@watson.ibm.com (Norman H. Cohen)]

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