Language lawyer question - private packages.

Language lawyer question - private packages.

[Chris Miller]

One for the language lawyers.

Assume that you have two sets of packages as followes :-

   package A is ... end;
   private package A.B is ... end;
   package A.B.C is ... end;

AND

   package A is ... end;
   private package A.B is ... end;
   private package A.B.C is ... end;--  * different.

Once a certain level of the tree is private (A.B), what is the
significance of making further children (A.B.C) private vs. public ?.

What operations and / or visibility will I have on one set of packages
that I will not 
have on the other set ?.

Any takers ?.

------------------------------------------------------------------------------------

Chris Miller
Sydney Australia.
chrismil@ozemail.com.au

Re: Language lawyer question - private packages.

[Robert A Duff]

In article <32E493CA.5001@ozemail.com.au>,
Chris Miller  <chrismil@ozemail.com.au> wrote:
>One for the language lawyers.
>
>Assume that you have two sets of packages as followes :-
>
>   package A is ... end;
>   private package A.B is ... end;
>   package A.B.C is ... end;
>
>AND
>
>   package A is ... end;
>   private package A.B is ... end;
>   private package A.B.C is ... end;--  * different.

If you have a package A.Something_Else, then in the first example, it
can have "with A.B.C;" on its body, whereas in the second example, it
could not.  To any package outside the "A" hierarchy, it makes no
difference -- both A.B and A.B.C are invisible.

Think of the whole hierarchy.  The same rules apply at each level -- a
body (or private spec) can 'with' its private siblings, and a parent
body can 'with' its private children.  But not private grandchildren.
And remember that A is a (public) child of Standard.

In your second example, A.B.C is invisible outside the subsystem rooted
at A.B, whereas in your first example it is invisible outside the
subsystem rooted at A.

You can make subsystems and sub-subsystems, and sub-sub-systems, and so
forth.  For any given package, you need to understand that it is private
or public WITH RESPECT TO some particular ancestor -- that is, it might
be public with respect to its parent, but private with respect to its
grandparent.

Advice: Make packages "private" when you can.

- Bob

Re: Language lawyer question - private packages.

[Tucker Taft]

Chris Miller (chrismil@ozemail.com.au) wrote:
: One for the language lawyers.

: Assume that you have two sets of packages as followes :-

:    package A is ... end;
:    private package A.B is ... end;
:    package A.B.C is ... end;

: AND

:    package A is ... end;
:    private package A.B is ... end;
:    private package A.B.C is ... end;--  * different.

: Once a certain level of the tree is private (A.B), what is the
: significance of making further children (A.B.C) private vs. public ?.

If a child is private, it is only visible to its (immediate) parent, and the
descendants of its parent.  Hence, private package A.B.C is visible
to A.B and A.B.*, but not to A.  By contrast, a public child
is just as "visible" as its parent.  Hence, anything that can see the
parent can see its public children.  For example, public package A.B.C *is*
visible to grandparent A, and all descendants thereof (A.*).

: What operations and / or visibility will I have on one set of packages
: that I will not 
: have on the other set ?.

: Any takers ?.

See above.

: Chris Miller
: Sydney Australia.
: chrismil@ozemail.com.au

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