Re: Possible Ada deficiency?

["Randy Brukardt" <randy@rrsoftware.com>]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:gemini.i9yj3c0051not02as.nick.roberts@acm.org...
> "Randy Brukardt" <randy@rrsoftware.com> wrote:
>
> > The purpose of a child package is to extend its parent, often in ways
not
> > forseen by the parent's author. You're trying to prevent that purpose.
If
> > you don't want access to the private information, then don't write
> > children. You have to at some point trust programmers to do something
> > sensible; it's not the least bit hard to use 'Address or
> > Unchecked_Conversion to access the private information of a package, no
> > matter where you hide it.
>
> I think you're missing the point a little, Randy.
>
> Suppose there are some things in the private part of a package that you do
> want private children of the package to be able to see (and modify), and
> some other things in the private part that you do not want even private
> children to be able to see (or modify).
>
> In this case, it would seem it may be useful to have language construct
that
> allows this intention to be clearly stated, and enforced by the compiler.

There is, it's called the "body". :-)

> If the intention later turns out to be an obstacle, the construct can be
> changed or removed. But if the intention is /accidentally/ violated, it
> could be very useful for the compiler to detect it and flag it up.
>
> I suppose the problem is, such a construct would imply the need for a new
> kind of private child -- perhaps a 'private private' child ;-) -- which
> could access the secret stuff. And then one might have ultra-secret stuff,
> and then ultra-secret children, and so on.
>
> So possibly the argument against is that it would be overkill.

Right. When the ARG considered adding an extra part to package
specifications to support mutually dependent packages (which eventually was
handled with limited with), there were two major concerns:
1) the interactions of the visibility rules for private parts with other
rules of the language are already very complex (and hard to implement). We'd
be nuts to double those interactions with a new kind of package part.
2) How would the user be able to decide what part to put things in? Imagine
the world if all of these proposals had been accepted: package would have 5
parts! (abstract, visible, private, concealed, body).

The way to solve this problem is to figure out how to put more stuff into
the body, not inventing new kinds of parts. It has been claimed (correctly,
IMHO) that the private part originally was a hack to allow compilers to be
written more easily. Ada 95 gave it a second use (exporting stuff within the
subsystem to child units), and it is the conflict between the hack and the
legitimate use that is causing the problem. So the real solution is to get
rid of the requirement for the hack. But there currently isn't the will to
do that - maybe next time.

                           Randy.