Re: Possible Ada deficiency?

["Tucker" <tucker@yaletaft.com>]

danmcleran@hotmail.com wrote:
> I would like to know if anyone else thinks that the inability to hide
> private information from child packages is a deficiency in Ada95. I
am
> discussing ways to do this on another thread, (See Private area and
> child packages), but it seems wrong that one has to go through a
bunch
> of machinations to do something like this. Wouldn't a language
> construct for this be advantageous?

We considered this during the Ada 95 design process.
Our conclusion was that C++ public/protected/private
was analogous to Ada's "visible part of pkg spec"/
"private part of pkg spec"/"body of pkg".
C++ doesn't really have the equivalent of a "body."
If you want to add a new function that is only usable
within a given class, you generally still have to declare
it in the ".h" (unless you play games with "friends"),
which is a royal pain IMHO.

If you really need to declare something in a package spec,
but you don't want it visible to children, one solution
is to declare it in a nested package.  The private part
of a nested package is not visible to children.

One consideration, however, is that trying to hide something
from all possible future children may be overengineering.
Some C++ coding styles encourage use of "protected" rather
than "private," since it is hard to foresee all of the kinds
of extensions that might be necessary in the future.  However,
in C++, "protected" is troublesome during maintenance, since
*all* derivatives of a type can see its protected components,
no matter where the type is declared.  And the type hierarchy
below a type may be very large, and spread all over the place.

On the other hand, Ada's approach to "partial" privacy forces
any package which needs visibility to be given a name which
essentially makes it part of the "subsystem" where the data
is defined.  Although there is nothing preventing someone
from creating their own child of someone else's subsystem,
when they do that, they generally accept the fact that they
may need to be prepared to do some work next time a new
revision of the subsystem is released.  On the other hand,
in C++, you are generally encouraged to get the advantages
of reuse by creating lots of derivatives of a type, and you
are probably less likely to think you are signing up for
a potential maintenance burden when a new version of the
base type is released.  I agree it is a subtle distinction,
but in my experience, it creates the right kind of subtle
incentive.  When someone creates a child of someone else's
subsystem, they do so to export a bit more information,
rather than dumping all of their own logic into the child.
So the net effect is that the amount of code that has visibility
is smaller, and so the ability to accommodate a change to the
parent package is better.

>
> In C++ and Java, no private data can be seen by child classes. I
think
> that Ada would benefit from extending its information hiding
> capabilities by allowing a package writer to conceal type information
> from child packages.
>
> What if Ada had a keyword, I've chosen 'concealed' for the sake of
> discussion, to indicate that the implementation of a type was not
> visible to the outside world (including child packages)...

Wrapping the type in a nested package can be used to
accomplish approximately what you need.

-Tucker Taft