Re: Child packages

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

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