RE: [sv-bc] explicit package exports

It may be possible to obtain the intended behavior of local 
using the export construct itself. 

For example

package P;
  import Q::*;
  int i;
  int j;
  export  P::i;
  export  Q::*; 
endpackage

is equivalent to saying "local int j" in package P;

We may have to expand the scope of the "export" construct
to include the current package contents. 

By default "export P::*" is implied for all packages
P;

Thanks

Logie. 




-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Stuart Sutherland
Sent: Wednesday, September 13, 2006 11:39 PM
To: 'Gordon Vreugdenhil'; 'Steven Sharp'
Cc: sv-bc@eda.org; Brad.Pierce@synopsys.COM
Subject: RE: [sv-bc] explicit package exports


I agree that adding 'local' to package declarations is intuitive and
makes
for self-documenting code.  Since it is likely that it will be the
intent
that most package items will be visible to importers of the package,
only a
few, if any, items will typically need to be declared as local.  If, on
the
other hand, the export was used to make package items "importable" (a
new
word?), then to hide a small number of items would require explicitly
exporting almost all other package items.

I also think it makes sense to include local package items as part of
the
export proposal.  The two go hand in hand.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
  

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Wednesday, September 13, 2006 4:01 PM
> To: Steven Sharp
> Cc: sv-bc@server.eda.org; Brad.Pierce@synopsys.com
> Subject: Re: [sv-bc] explicit package exports
> 
> 
> I actually like "local".  It has the right semantic intent
> and is a trivial change to the declaration form.  I nearly
> added that on Monday in to the sub-group proposal I made for
> export control but didn't want to muddy the waters.
> 
> We definitely do have overloading of keyword meaning.  The
> export proposal will add to that by using "export" in a
> new way.  Using "local" as part of a package declaration
> makes intuitive sense to me and I don't think we need to
> tie that to class semantics -- "local" has (at least to me)
> a natural meaning for packages.
> 
> This fits very well with my thinking about the interface
> (the visible names) and implementation of a package as
> separate things.  Re-export allows interface propagation;
> localization allows implementation to be hidden.  You can
> do a lot with that combination.
> 
> Gord.
> 
> 
> Steven Sharp wrote:
> 
> >>The keyword 'local' could be used for data hiding, as in 7.17.
> > 
> > 
> > It could, but that seems like an ugly hodgepodge.  You have some
> > kind of export mechanism to make imported symbols visible, but
> > a different mechanism borrowed from classes to control visibility
> > of declared symbols.
> > 
> > It would be more consistent if we took Cliff's suggestion of
> > borrowing 'extends' from classes also.  However, the 
> current 'extends'
> > syntax only accounts for a package building on top of a single base
> > package.  If it needs to import symbols from multiple other 
> packages,
> > then it needs a syntax for multiple inheritance.  And it still isn't
> > consistent with the existing use of import to access symbols.  Users
> > of classes don't use import to get access to the contents 
> of a class.
> > 
> > Steven Sharp
> > sharp@cadence.com
> > 
> > 
> 
> -- 
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
>