children

children

[Peter Hermann]

for the sake of gaining other opinions I am posting (with agreement)
an off-line discussion between eachus@spectre.mitre.org and me(ph).

topic: child packages talk about parent's secrets:
       break of information hiding.

ph:>   > I would not recommend that whole direction because
   >   > one of the strengths of the child feature is exactly the fact,
   >   > that the parent need not be touched further on.
             ^ the code of

ea:>    I work in a field where this alternative is not acceptable.  A
   > modification which affects the value of variables in a package must be
   > reflected in the documentation., etc.
   > 
   >    The benefit of this proposal is that, if the pragma is never used,
   > the user is never bothered.  In the sort of project that concerns me,
   > just before FQT (Formal Qualification Test) the programmers would run
   > a tool to put in the pragmas, and any further modification of the
   > structure would be immediately obvious.  So it would be a big help
   > during maintenance, and no hindrance during development.  Seems
   > win-win to me.

ph:Your argument qualifies well to be spread to all in c.l.a. .
   We are all in search of the best possible solution for Ada0X
   and I think there should be further discussion on those 
   topics. Maybe we are both right. Or I am wrong....   , but:
   Some new ideas for this one topic should be found.
   For quality assurance you are extremely right above.

   What attracts me, are the advances in SE-principles, OO-principles,
   e.g. that a piece of software remains unchanged.

   For our special problem it is conceivable that
   a compiler is able to detect "nasty children"
   in the same way as "non-portable constructs".
   This would be an acceptable way for me, too.

ea:
   Good point.  If the compiler is detecting illegitimate children, it
could also warn of any violation of good OO and SE principles, by that
child.  Let's see...I'd want a warning for any direct assignments to
variables in the body or the private part, and any overriding of
dispatching operations for types declared in the parent.  Anything
else?

   Both of those checks seem very easy to add to a compiler, and both
are in the category of practices which are useful, but (potentially)
dangerous.  However, I think there are a lot of other things that I
want compiler vendors to worry about first.  My only reason for
bringing the pragma up was that users can start adding it as
documentation with no compiler support, and/or support by other tools,
but we need a consensus on the spelling.

Re: children

[Robert Dewar]

OK, Eachus works in an environment where this kind of control is required,
but his configuration management system is incompetent and cannot provide
this kind of support.

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.

Re: children

[Norman H. Cohen]

In article <3kv64j$1fhh@info4.rus.uni-stuttgart.de>,
ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) quotes Robert
Eachus as follows: 

|> ea: 
|>    Good point.  If the compiler is detecting illegitimate children, it
|> could also warn of any violation of good OO and SE principles, by that
|> child.  Let's see...I'd want a warning for any direct assignments to
|> variables in the body or the private part, and any overriding of
|> dispatching operations for types declared in the parent.  Anything
|> else?

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 :-) ).

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

Re: children

[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

Re: children

[Robb Nebbe]

In article <D68E9I.6DH@thomsoft.com>, kst@thomsoft.com (Keith Thompson) writes:
|> Mind you, I *like* child units, and I'm glad that Ada 95 has them.
|> I'm just suggesting that a little bit of theoretical security has been
|> lost relative to Ada 83; it's not surprising that a lot of people are
|> uncomfortable with that.

I am not surprised that people might initially react to the
perceived loss of security but once you have thought about it
I don't see how they can continue to worry about it.

My perspective is that child units substantially increase the
flexibility of the langauge. I want the language to protect me
from accidental mistakes and inconsistent models. I like the
fact that Ada makes me say what I mean but once I have said it
I don't want the language to second guess me I want it to
make sure I stick to it.

For me child units replace several uses of Unchecked_Conversion
and cases where I would have had to nest a package inside
another. If I would have put something in another package in
Ada83 I will not put it in a child package in Ada95. Of course
there is nothing in the language to stop me from doing this
but there is nothing in Ada83 to stop me from nesting a package
inside another either.

The need for a pragma to restrict unwanted children is really
no more important that a pragma to restrict unwanted nested
packages, which we seemed to do fine without in Ada83.

Robb Nebbe

Re: children

[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...

Re: children

[Keith Thompson]

In <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.

It seems to me that a lot of the arguments against adding a language
feature to restrict child units could as easily be made against enforcing
the privacy of private parts/types at all.  Consider something like this:

    package Stacks is
	type Stack is private;
	procedure Push(...);
	procedure Pop(...);
	...
    private
	Max_Length: constant := ...;
	type Stack is
	    record
		TOS: Natural := 0;
		Elements: array(1 .. Max_Length) of ...;
	    end record;
    end Stacks;

    with Stacks;
    procedure Client is
	My_Stack: Stacks.Stack;
    begin
	...
    end Client;

Why, one might argue, should the language prevent Client from accessing
My_Stack.TOS and My_Stack.Elements directly when a sufficiently clever
CM system could enforce the restriction?

Yes, this is an exaggeration of the issues, but I think it illustrates
the point.  

I think the reason for all the brouhaha is that Ada 95, by adding child
units, has slightly weakened the privacy of private parts.  An Ada 83
private part is theoretically inviolate (barring Unchecked_Conversion
or modification of the source and recompilation of whatever depends on
it, of course).  An Ada 95 private part isn't, and there's no convenient
way to enforce the same level of privacy provided by Ada 83.

Counterarguments, of course, are that the privacy isn't violated unless
you "with" the child unit, and you can get back the same level of privacy
by some minor contortions with nested private parts; that's why I said
it's *slightly* weakened.

Mind you, I *like* child units, and I'm glad that Ada 95 has them.
I'm just suggesting that a little bit of theoretical security has been
lost relative to Ada 83; it's not surprising that a lot of people are
uncomfortable with that.

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.