Re: Child packages

[jgv@swl.msd.ray.com (John Volan)]

mbk@inls1.ucsd.edu (Matt Kennel) writes:

>Robert I. Eachus (eachus@spectre.mitre.org) wrote:
>: In article <3816h5$n3g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

>:  > One thing that should be emphasized about child packages (since some of
>:  > the posts of this thread have not been clear on this point) is that
>:  > child packages in no way change their parents. If you have a parent A,
>:  > and a child A.B, then if A.B does horrible things to the abstractions
>:  > in A, it still does not affect anyone who with's only package A. It is
>:  > only if package A.B is with'ed that the effects of the child are
>:  > noticable.

>:      Very misleading.  If a PROGRAM doesn't include any withs of a
>: child, the child is not part of that program and can't harm it.  But a
>: child unit can--even during elaboration--change hidden state in the
>: parent's private part. 

>Question:  do you mean objects declared to be type of the parent
>may be harmed due to the fact that there are subclasses of
>this parent?  This sounds dumb.  This isn't true, is it?

>Of course, if you create a child class which takes some implementation
>from a parent sure you might screw up the implementation taken from
>the parent, but this should only affect you if you use
>objects of the child class, right?

Matt, you are confusing child units and package hierarchies with
inheritance and class hierarchies.  They are not the same thing.
Child units and package hierarchies are a pure "modularity" concept,
one that that is new to Ada9X.  The hierarchical library mechanism
deals with issues of scope, visibility, encapsulation, information
hiding, and separate compilation.  On the other hand, class
hierarchies and inheritance, well-known in so many object-oriented
languages, are treated as a "typing" concept in Ada9X, and are
implemented in terms of tagged types, type derivation, and type
extension.

Your background as an Eiffel programmer is showing.  Eiffel is a
language designed to adhere to the principle of 1 MODULE = 1 TYPE.
This principle is the "One and Only True Way" of today's
object-oriented orthodoxy.  But the design of Ada (83 and 9X) makes no
attempt to rigidly follow that orthodoxy.  Mind you, it doesn't
*preclude* the idea of 1 MODULE = 1 TYPE.  Indeed, as I've been trying
to show on another thread, it's possible to adhere to a style of 1
PACKAGE = 1 CLASS even under the most strenuous conditions without
resorting to grotesque workarounds.  However, Ada9X doesn't *require*
you to follow this style as the "One and Only True Way".  In fact,
Ada9X's hierarchical library allows programmers to deal with
modularity issues at levels of granularity *beyond* the class-level
(e.g., "subsystems") -- *without* having to look beyond the
programming language for support. At the same time, it supports
levels of granulatiry *smaller* than the class-level (different
aspects of a class's functionality might be dealt with in different
child units -- well, as long as that functionality doesn't have to
be "primitive").

If you haven't already done so, it might help you to download and read
the Ada 9X Rationale, which is available by anonymous FTP from the
AJPO host, in

	ftp://ajpo.sei.cmu.edu/public/ada9x/rm9x

>--
>-Matt Kennel  		mbk@inls1.ucsd.edu
>-Institute for Nonlinear Science, University of California, San Diego
>-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
>-***     lyapunov.ucsd.edu, username "anonymous".

-- John Volan

--------------------------------------------------------------------------------
--  Me : Person := (Name                => "John Volan",
--                  Company             => "Raytheon Missile Systems Division",
--                  E_Mail_Address      => "jgv@swl.msd.ray.com",
--                  Affiliation         => "Enthusiastic member of Team Ada!",
--                  Humorous_Disclaimer => "These opinions are undefined " &
--                                         "by my employer and therefore " &
--                                         "any use of them would be "     &
--                                         "totally erroneous.");
--------------------------------------------------------------------------------