Re: children

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <3l6p9s$12kj@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:

  > What I really want is something I can't have: Detection of a child
  > manipulating the representation of a private type in a way that
  > violates the representation invariants that the parent's author
  > had in mind (and probably forgot to document :-) ).

    But it is not totally out of reach, which is one of the things I
like about the final version of child packages.

    Assume a design paradigm where any legitimate private operations
on the type or types exported by a package use procedures and
functions declared in the private part.  (These are in effect C++
friend functions.)  Now unless you have a limited public view and a
non-limited private view, the only way to violate the invariants is to
reference subcomponents of the type.  This is the sort of thing that a
compiler or ASIS based tool should be capable of doing.  (Find all
references in child units to operator symbols, object and component
names, and types declared in the private part.)

    Of course it doesn't work if the implementor of the type forgot to
document all the operations legal in child units.  But the failure
mode is safe--the undocumented operation just isn't permitted.

    This may seem like a lot of bother, but it really isn't.  In the
case of a private type whose completion is the renaming of a type
exported by a generic instantiation, put the instantiation in the
private part and you are all done.

    For example, imagine a FIFO queue implemented using a generic
double-ended queue.  Child units can "break" the FIFO discipline, but
without Unchecked_Conversion or the like can't break the invariants of
the double-ended queue.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...