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
>