Solo Programadores 22/SOLO_22.iso/docs/lovelace/lesson15.les

Text File | 1995-11-21 | 7.4 KB | 178 lines

<COMMENT This is a lesson file for the Lovelace Ada tutorial>
<COMMENT A program called genlesson is used to transform this file into a set>
<COMMENT of useful HTML files for use by Mosaic & other WWW browsers.>

<COMMENT  Edit the following lines. >
<TUTOR NAME="Lovelace">
<LESSON NUMBER=15>
<AUTHOR NAME="David A. Wheeler" EMAIL="[e-mail]">
<AUTHOR ADDRESS="<A HREF="dwheeler.htm">David A. Wheeler ([e-mail])</A>">
<COMMENT $Id$ >

<COMMENT  You'll probably want to uncomment and edit these lines: >
<COMMENT  <PREVIOUS_LESSON LOCATION="URL_of_directory/" >
<COMMENT  <NEXT_LESSON LOCATION="URL_of_directory/" >

<COMMENT A lesson is divided into 1 or more "sections".>
<COMMENT Each section has a title; SECTION starts a new section.>

<SECTION NAME="Ada Program Structure">
Because this is a tutorial I've used very short programs to
demonstrate specific points.
Real Ada programs are developed instead as a set of (many) Ada packages.
Each package has a declaration that publicly declares the facilities
it makes available, and each package has a body to implement that public
declaration.
<P>
Packages are the principle structuring facility in Ada.
Packages are intended to be used to directly support abstraction,
information hiding, and modularization.
For example, packages are useful for encapsulating machine dependencies.
<COMMENT This is a quote from AQ&S chapter 4 >
<P>
It isn't easy to describe program structuring issues, because that's
really a program design question, not just a language question.
Some recommendations are given in
<A HREF="ftp://sw-eng.falls-church.va.us/public/AdaIC/docs/style-guide/95style/ps/struct.ps">Chapter 4 ("Program Structure") of
<EM>Ada Quality and Style: Guidelines for Professional Programmers.</EM></A>
Here are some of those guidelines:
<P>
<UL>
<LI>
Packages should serve a single purpose.
You should avoid creating packages that are
simply collections of unrelated objects and subprograms.
<LI>
You should use a package to group together closely related types.
For example, you might have a
"vector" type (a one-dimensional list of numbers)
and "matrix" type (a two-dimensional list of numbers).
In this case, you could have a single package
called <EM>Matrix_Manipulation</EM> with both types defined in it.
<LI>
Put only what is needed for the use of a package into its
specification; hide the implementation details from the users.
<LI>
In general,
avoid defining a variable in a package specification, since that
creates a global variable visible to anyone who <EM>with</EM>s the package.
<LI>
Minimize the number of declarations in a package specification.
<LI>
Only use <EM>with</EM> clauses where they are needed.
In particular, if you can move a <EM>with</EM> clause so that it's used by
the package body instead of the package specification,
you should do so.
</UL>
<P>

Note that Ada is different from some other languages.
Ada separates the concept of <EM>type</EM> from
the concept of <EM>module</EM> (package); some other languages
merge the two concepts (particularly Eiffel, and to a lessor degree C++).
Each approach has its advantages and disadvantages, which we
won't delve into here.
<P>


<SECTION NAME="Child Packages">
Ada 95 has added a new capability called a "Child Package."
A child package is a package that is conceptually part of its parent
package, but a child package can be compiled
separately (after its parent has been compiled)
without recompiling or modifying the parent.
This can reduce recompilation time and it provides another mechanism for
breaking a complicated system into components.
<P>
Child packages are especially useful if you define
a private tagged type in a package.
A child package can "see" the definition of a private tagged type,
because conceptually the child package is part of the parent package.
<P>
We'll go over child packages briefly here, but feel free to skim this section
and return later if you like.
<P>
To understand how child packages work, let's first repeat the fundamentals.
Any package can have a declaration (specification) and a body, and the
package declaration can have both a public part and a private part.
Normally the private part of the package declaration can only be seen by
the body of package X;
anyone who "with"s package X may only see the public part.
<P>
A child package adds a few twists. First,
a child package is considered to have "automatically with'ed" its parents.
In the public part of a child package you can only see the public part of your
ancestors, just as though the package had the statement
"with Parent" at the top.
The real difference, though, is what happens in the child package
declaration (specification) private part and body - in those places,
the <EM>private</EM> part of the child packages' ancestors
are made visible.
That's an important difference - normally packages do <EM>not</EM>
have visibility to the private parts of other packages, because
conceptually the child package is part of the parent's package.
<P>
Let's go through an example to make this clearer.
Let's say you have a package named "X".
Package X can a declaration (specification) and a body, and package X's
declaration can have a public part and a private part.
Normally only package X's body can see the private part of the package
declaration; anyone who "with"s package X may only use the public part.
<P>
<IMG ALIGN=right SRC="childp.gif" ALT="[Child Package]">
Now, let's define a child package of X, called "X.Y".
Package X.Y's public part can see the public part of X automatically, and
the private part of X.Y and the body of X.Y can automatically see the
private part of package X.
This isn't considered a violation of Ada's safety rules,
because X.Y is considered to be part of X.
<P>
The syntax for declaring a child package is the same as ordinary packages,
you just name the child package using dotted notation:
<P>
<PRE>
  package X.Y is ....
  end X.Y;
</PRE>
<P>
<IMG ALIGN=right SRC="pchildp.gif" ALT="[Private Child Package]">
You can also have <EM>private</EM> children (the normal kind of children
are called <EM>public</EM> children).
Private children are intended for "internal" packages that should only
be "with'ed" by a restricted number of packages.
Private children can only be "with'ed" by the body of its parent or by
descendents of the private child's parent.
In exchange for such a restrictive requirement, a
private child gets a new authority:
a private child's specification automatically sees both the public and
private parts of all of its ancestors' specifications.
To declare a private package, just append the word "private":
<P>
<PRE>
  private package X.Z is ....
  end X.Z;
</PRE>
<P>
You can <EM>with</EM> a child package by specifying its parents in dotted
notation.
Whenever you name a child package in a "with" statement, you
automatically "with" all of its ancestors.
For example, if package "Ada" has a child package
named "Strings", which then has a child
package named "Unbounded", you would say:
<PRE>
  with Ada.Strings.Unbounded;
</PRE>
<P>
When you "with" Ada.Strings.Unbounded, you automatically "with" the
packages "Ada" and "Ada.Strings".
That doesn't mean that you automatically "use" them; you can then "use"
whichever packages you wish.
<P>
<P>
There's a lot more about child packages that we won't cover now.
<A HREF="http://lglwww.epfl.ch/Ada/LRM/9X/Rationale/rat95html/rat95-p1-2.html#7">The
Ada Rationale section II.7</A> describes child packages
(also called hierarchical libraries) in more detail if you are curious.