Re: children

[kst@thomsoft.com (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'.