Re: [sv-bc] Query regarding package export

Alok,

   One goal of package re-export is to allow packages to encapsulate an API.
   To achieve this in your example, p1::x must become a first-class
   name exported by p2 and each of the others.  Of course, internally, it
   must retain its identity as p1::x; perhaps this confused your "standard simulator".

   The name "x" in each of these package scopes has a local property ("exportable")
   which indicates whether it has any outside visibility via a package-scope operator
   reference ("Pn::x").  But this property is not attached to the item's
   ultimate definition (p1::x), instead it must be maintained separately for
   each of the relevant package scopes which maintain some "symbolic link"
   to the final item definition.

   The uses of package_scope operator in an export statement refer to these
   local images of the external packages.
   Only with this comprehensive record of the complete namespace of each
   package scope can a separate "export" statement hope to figure out your intentions.

SV-BC,

   I have a more difficult question, though.
   Excerpting from the LRM example in 26.6:

package p1;
   int x, y;
endpackage

package p2;
   import p1::x;
   export p1::*;     // exports p1::x as the name "x";
                     // p1::x and p2::x are the same declaration
endpackage

package p4;
   import p1::*;
   export p1::*;
   int y = x;
endpackage

----------------------------------  Now I'll ask my questions:
package top1;
   import p2::*;
   import p4::*;
   int y = x;    // x is p1::x - but we don't know which wildcard "imported" it.

   export p4::*; // So, will this only export p1::x half the time, or on half the systems?
endpackage

package top2;
   import p2::*;
   int y = x;    // x is p1::x - Now we know which wildcard "imported" it.
   import p4::*;

   export p4::*; // Will this still export p1::x?
endpackage


My personal answers are that in top1, both wildcard imports had to agree,
so both p2 and p4 are providers of p1::x, and either can authorize its export.
But in top2, p4 was not a party to the original wildcard import, and in fact,
could legally contain an incompatible definition for x.
p4 did not provide x to top2, so it cannot authorize the export of top2::x.

But I'd be interested to hear other reactions,

Greg

Alok Kumar Sinha wrote:
> Hi,
> 
> LRM P1800-2009-draft7a defines export statement in section "26.6
> Exporting imported names from packages" with some examples. I have the
> following question regarding that.
> 
> Can I expect an exported item via another package is visible to the
> scope where the via package is actually imported instead of the package
> which actually exports? LRM is not clear on that. And the standard
> simulator which supports export is not consistent too.
> 
> Consider the following e.g:
> 
> package p1;
>     int x,y;
> endpackage
>  
> package p2;
>     import p1::x;
>     export *::*;      // p1 :: x is made available from here.
> endpackage
> 
> package p3;
>     import p2::*;
>     export p2::*;
>     int z = x;        // Since x is being referenced,   is p1 ::  x  is
> made available from p3 ?
>                           
> endpackage
>  
> module top;
>      import p3::*;
>      int z = x;     // Is it legal and refers to p1::x ?
> endmodule
> 
> The standard simulator is failing on above case complaining for
> undefined 'x' in module top.
> Please note that if in package 'p3',
>    export p2::*
>  is replaced by
>    export p2::x
> then it is fine.
> 
> I think both of them should be fine.
> 
> Thanks and Regards
> Alok
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.