RE: [sv-bc] explicit package exports

If you want, think of 'local' as coming from 'localparam'. Like a
localparam in a module, a local identifier in a package is for the
convenience of package writer and is not for others to import. Does that
make it 'feel' any better?

I think this functionality is needed regardless of considering export.
You just can't export an identifier that can't be imported. I have real
trouble thinking about why you would allow an identifier to be imported,
but not exported

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Steven Sharp
> Sent: Wednesday, September 13, 2006 3:22 PM
> To: sv-bc@server.eda.org; Brad.Pierce@synopsys.com
> Subject: Re: [sv-bc] explicit package exports
> 
> 
> >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