Re-exporting features from private packages...

Re-exporting features from private packages...

[Dale Stanbrough]

Ada prevents a public package withing a private package presumably to
prevent the private info being exported. However this rule seems too
restrictive.

A simple rule change would seem to allow a much more flexible use of
private packages that would not compromise security. If a package
spec was allowed to 'with' a private package, but only refer to it in
its private section, it would seem we could have the best of both worlds.

This could be signalled by a special syntax...

	with private Blah; use Blah;


or simply by allowing it, with no change in syntax.

Are there any reasons why this would not be a good thing?


Dale

Re: Re-exporting features from private packages...

[Tucker Taft]

Dale Stanbrough (dale@goanna.cs.rmit.EDU.AU) wrote:

: Ada prevents a public package withing a private package presumably to
: prevent the private info being exported. However this rule seems too
: restrictive.

: A simple rule change would seem to allow a much more flexible use of
: private packages that would not compromise security. If a package
: spec was allowed to 'with' a private package, but only refer to it in
: its private section, it would seem we could have the best of both worlds.

: This could be signalled by a special syntax...

: 	with private Blah; use Blah;


: or simply by allowing it, with no change in syntax.

: Are there any reasons why this would not be a good thing?

Private child units might have better been called "body" child units.
They are logically extensions of the body, and are only visible to
other private units, and to bodies.  This ensures that you can
add, remove, or alter private child units without ever requiring
recompilation outside the subsystem (presuming no generic/inlined bodies
depend on them).

One could have defined them otherwise.  However, you can in fact already
accomplish what you want by defining a public child unit with 
everything in its private part.  It can then be mentioned in "with" 
clauses, but its (private) declarations are only visible inside the 
private part of other public child units.

: Dale

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Re-exporting features from private packages...

[Samuel Mize]

In article <5dp10k$19h$1@goanna.cs.rmit.edu.au>,
Dale Stanbrough  <dale@goanna.cs.rmit.EDU.AU> wrote:
>If a package
>spec was allowed to 'with' a private package, but only refer to it in
>its private section, it would seem we could have the best of both worlds.

In Ada95, you can do this!  With certain restrictions.

Only a given package can see its private variables or types.  This
lets you reason about the behavior of all subprograms that operate
on such items.  Once you've verified the subprograms in that package,
nothing else can invalidate them.

We'd like to extend a package, without having to recompile or break
other programs using the package.  We would make package Extend as
an extension of package Base, and Extend could see Base's private items.

Extend, in Ada95, would be a "child" package of Base.  Its full name
would be Base.Extend .  This is one intended use of child packages.

However, Ada won't let Extend be a child of more than one package.
This may make it harder to build the system you want, given an
existing set of packages.

>[special syntax to "open" a private part]
> would seem to allow a much more flexible use of
>private packages that would not compromise security.
...
>Are there any reasons why this would not be a good thing?

The unity of a package, and the guarantee that no other will mess
with its private items, makes it *MUCH* easier to maintain, debug,
or extend that package.  (In Ada95, for this purpose, we think of the
package and all its children together.)  We don't have to hunt through
the whole program, seeing if any other code has screwed up the
package's internals.

In fact, Ada was designed to be easier to read and maintain, even if
that made it harder to write.

I work in a team.  If a package I use has changed, I have to recompile.
If I don't have to recompile my code, chances are excellent that
nothing has screwed up the packages it depends on.

If an arbitrary other package could alter the private parts of those
packages, I'd have to watch for bugs due to a "quick fix" by someone
else who *thought* he understood the shared package's design.

Happy coding!

Samuel Mize