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,57fc00da1adfa079
X-Google-Attributes: gid103376,public
From: Robert A Duff <bobduff@world.std.com>
Subject: Re: LLQ: Scope and child package names
Date: 2000/08/11
Message-ID: <wccbsz0dodt.fsf@world.std.com>#1/1
X-Deja-AN: 657123703
Sender: bobduff@world.std.com (Robert A Duff)
References: <8mv91i$bfr$1@nnrp1.deja.com>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 2000-08-11T00:00:00+00:00
List-Id: <comp.lang.ada>

Ted Dennison <dennison@telepath.com> writes:

> My compiler's giving me some suprising (to my small mind) results in
> this area, so I'd like to find out what the actual rules are in this
> area.
> 
> Say I have two child packages, one of which "with"s the other. Let's
> further stipulate that the name of the with-ee's parent happens to be
> the same as the name of the with-or. For example:
> 
> package Foo.Utility is
>    type Instance is...
> ...
> end Foo.Utility;
> 
> with Foo.Utility;
> 
> package Facility.Foo is
> ...
>    type Instance is new Foo.Utility.Instance;
> end Facility.Foo;
> 
> My compiler gacks at this, saying Utility is not found in Foo. I'm
> guessing the problem is that "Foo" inside of Facility.Foo is a shorthand
> for Facility.Foo, hiding any "Foo" package hierarchy I may have with'ed.
> Is that right?

Yes.

Child packages behave (more or less) as if they were physically nested
in their parent.  Imagine that you had written these packages physically
nested, and then imagine which Foo hides which other Foo where.  Make
sense?

Eg:

procedure Main is
    package Foo is
        package Utility 
    ...etc

> Question 2:
> 
> It just so happened that I had a rename for the with-ee parent around.
> So I tried using that, expecting failure becuase I had no such rename
> for the child package. But to my suprise, it worked! Eg:
> 
> package Executive_Foo renames Foo;
> 
> with Executive_Foo.Utility;
> 
> package Facility.Foo is
> ...
>    type Instance is new Executive_Foo.Utility.Instance;
> end Facility.Foo;
> 
> This compiled happily. So a rename of a package effectively acts as a
> rename for all its children too?

There's nothing special about children when it comes to renaming.  If
you have a name for a package, you can refer to stuff in the package if
that stuff is visible, by saying Package_Name.Whatever.  It doesn't
matter whether Package_Name is a renaming or not.  And it doesn't matter
whether Whatever is a child package, or a nested package, or an integer
type nested in the package, or anything else.  The only thing special is
that children aren't visible unless with'ed.

- Bob