RE: [sv-bc] explicit package exports

As a general design principle, I think we should remember that sometimes
it is easier, from a user's point of view, to say, "Do X", and sometimes
it is easier to say, "Don't do X". 

Since that formulation is probably not clear, let me illustrate with an
example. With $dumpvars, we have the ability to say, "dump everything in
a scope". We also have the ability to say, "Dump X, Y, and Z". What we
lack is the ability to say, "Dump everything EXCEPT X, Y, and Z".
Sometimes that last formulation is easiest to write. 

Covergroups did this nicely, with both bins and ignore_bins.

So both the ability explicitly specify what to export and what not to
export would be nice if possible to implement reasonably.

Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Gordon Vreugdenhil
> Sent: Thursday, September 14, 2006 2:01 AM
> 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