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,5631add016610868
X-Google-Attributes: gid103376,public
From: Gene Ouye <geneo@rational.com>
Subject: Re: Ada95 visibility problem
Date: 1996/02/26
Message-ID: <NEWTNews.825369958.31303.geneo@medusa.ppp.rational.com>#1/1
X-Deja-AN: 141278770
references: <4gl9on$8o4@hacgate2.hac.com>  <4gsrn2$9d0@wdl1.wdl.loral.com>
content-type: TEXT/PLAIN; charset=US-ASCII
organization: Rational Software Corporation
mime-version: 1.0
newsgroups: comp.lang.ada
Date: 1996-02-26T00:00:00+00:00
List-Id: <comp.lang.ada>


mab@dst17.wdl.loral.com (Mark A Biggar) wrote:
> In article <4gl9on$8o4@hacgate2.hac.com> ddavenpo@redwood.hac.com (Darren C 
Davenport) writes:

   [Darren doesn't know why a generic child unit isn't seeing declarations
    in the parent that should have been made visible by a use clause.]

> >-------------------------------------------------------------------
> >generic
> >package x is
> >  package z is
> >    function c return integer;
> >  end z;
> >  use z;
> >end x;

   [x'body deleted...]

> >generic
> >package x.d is 
> >  function d return integer;
> >end x.d;
> >package body x.d is
> >  function d return integer is begin return c; end d;
> >end x.d;
> >with x;
> >package k is new x;
> >with x.d;
> >package k.l is new k.d;

   [x.d error message deleted...]

> This is a real error, need to either say "z.c" or add a "use z;" to the 
> declarations set of package body x.d before the function body.

Actually, if you look in the declaration of the specification of x,
you'll see the use clause is already there.  That should make all the 
public declarations in x.z (like the function c) visible to all the 
descendants of x.

> >Now, if package x is not generic all is well.  What's the difference?

sounds like a problem with generics...

> If this is true then it is the non-genreic case that is the error
> (and an undetected one at that).

The use clause in the spec should work for the non-generic case as well.

   [...]

> Agreed, but you still have to use dot-selection to access the components
> of a visible package for which you don't have a use clause.

Did you just miss the use clause in x'spec or am I missing something
about the visibility rules?  (which wouldn't be a big surprise...  :-)

Gene Ouye <geneo@rational.com>