TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Date: Tue, 20 Oct 1998 12:12:52 -0500
Reply-To: Samuel Mize <[log in to unmask]>
From: Samuel Mize <[log in to unmask]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]> from "Daniel Wengelin" at Oct 20, 98 03:12:37 pm
Content-Type: text/plain; charset=US-ASCII
MIME-Version: 1.0
Parts/Attachments: text/plain (36 lines)
Daniel Wengelin asks whether Ada 95's child/private packages can provide
visibility control similar to:
>a programming environment that supports "export sets"
> from components, i.e. the ability to define for a given software component
> (CSC, say 10-50 kSLOC) the package specifikations that are allowed to be
> "with"ed from another component.

Yes, I believe so.  This kind of partitioning is discussed in the Ada 95
Rationale in section II.8.  It was a motivator for the whole idea of
child and private child units.

I'm very rusty on the specific syntax and semantics -- we aren't using
these features in my current work -- but here's the general idea.

You start with a package CSC_01.  This may have child packages.  These
can be "with"ed by any other package, whether or not that other package
is a child of CSC_01.  You can consider these child packages to be your
"export set."

If a package is defined to be a PRIVATE child of CSC_01, it may ONLY
be "with"ed by the body of another child of CSC_01, or by the SPEC
of another PRIVATE child of CSC_01.  Thus it's invisible outside
the CSC_01 child hierarchy, but it can be used to implement the
routines provided by your "export set" packages.

For further info I recommend the Ada 95 Rationale, then the Ada 95
Reference Manual (the ARM).

Sam Mize

Samuel Mize -- [log in to unmask] (home email) -- Team Ada
Fight Spam: see \\\ Smert Spamonam