From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,579fe8b368f918a7
X-Google-Attributes: gid103376,public
From: smize@news.imagin.net (Samuel Mize)
Subject: Re: Re-exporting features from private packages...
Date: 1997/02/20
Message-ID: <5ej38k$15m0@prime.imagin.net>#1/1
X-Deja-AN: 220302513
References: <5dp10k$19h$1@goanna.cs.rmit.edu.au>
Organization: ImagiNet Communications Ltd, Arlington, Texas
Newsgroups: comp.lang.ada
Date: 1997-02-20T00:00:00+00:00
List-Id: <comp.lang.ada>


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