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