Re: children

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

In article <3l3kp9$rgv@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> We can't do *everything* a CM does in Ada. The question is always how far
|> to go. There is therefore no principle involved here, just a matter of
|> practicalities and pragmatic convenience. After all if you have no CM at
|> all the discussion is silly, since you can always edit the source and
|> remove the pragma anyway.

Obviously, marking a package as having no children, or marking its
private part as off limits to children, does not protect the package
against "unauthorized" modification.  Obviously the kind of tools that
can protect a package against unauthorized modification CAN, IN
PRINCIPLE, be extended to protect against unauthorized addition of
children.  A package marking could serve to bridge the gap between the CM
tools that could exist in principle and those that exist in reality--but
only after we have bridged the gap between compiler checks that could
exist in principle and those that exist in reality!

Such marking does serve to inform the reader of the program that all the
code having access to the private part is encapsulated in the package
body, and thus aids program understanding.  However, Tucker and his team
took pains--painful pains in the case of the rules for instantiating
children of generics--to ensure that all child units having access to the
private part of a package P have names beginning  P.__; the point of
Tuck's recent oblique reference to GNAT users issuing a list-files
command was that, if GNAT naming conventions are followed, the command

   dir P-*.ads

lists the declarations of precisely those children.  For a compiler based
on a traditional program library, an alphabetical listing of compilation
units can provide the same information.  So marking the parent to provide
compiler-checked information to the reader is nice, but there are other
ways to obtain the same information.  (Purists might argue that
encapsulation has been violated, but in fact the "capsule" has just been
distributed over several compilation units, as with Ada-83 subunits.
Access to the private part of the parent is still confined to a small,
clearly identifiable, part of the program.)

A no-children marking can serve as a warning to the reader that the inner
workings of the package are complex, with many subtle representation
invariants, and should not be tampered with casually.  Unlike a comment,
a compiler-enforced marking commands the attention of the would-be author
of a child package, at least for as long as it takes to remove the
marking from the parent package.  However, since the language offers no
comparable protection against casual modification of the parent itself,
it is hard to justify such protection against the addition of children.

A no-children marking can serve as a statement of ownership and
responsibility: By inserting such a marking, the author of a package
states that he stands behind the package as delivered.  Adding children
is tantamount to opening the back cover and voiding the warranty.  Of
course comments can be used to make the same statement.

In short, there are a number of plausible benefits to a no-children
marking--and also a number of plausible ways to achieve these benefits
without such a marking.

[Digression:  I heard a story--which may or may not be true but is worth
telling anyway--of someone who called the vendor from whom he bought his
PC to complain that the hard drive wasn't working correctly.  The
customer-service rep asked, "Did you check that the connectors weren't
loose?" "Yes," responded the customer, proud to demonstrate that he was
technically competent and one step ahead of the rep.  The rep replied,
"Well, if you opened the box, you voided the warranty," and hung up.]

--
Norman H. Cohen    ncohen@watson.ibm.com