The problem is that one might want to distinguish: import p1::*; import p2::x; export p2::*; If the "export p2::*" has import semantics, then you can have collisions with p1 that would otherwise be avoided. Yes, you could explicitly export just the names you wanted but there have already been complaints about redundancy. Gord. Greg Jaxon wrote: > Gordon Vreugdenhil wrote: > >> I think that it would be a bad idea to have "export pkg::*;" be >> an implied import. > > > As I understand it, the product in question implements import pkg::* > as wildcard import with implied export. So I thought that switching > the keyword was the obvious resolution of this syntax collision. > > If export pkg::* also exported unused candidates, I'd agree this > is a bad idea. But that is not the definition I've heard proposed. > > I suppose you mean that it would be a bad idea because it gives > end users a way to say "export everything I import from pkg". > I don't see the problem, since the package author is still in > charge of what he actually exports, and thanks to having /both/ > import and export variations, he has far better control than in > either product currently in service. > > On the contrary, I think it is a bad idea to have a new error > possibility in the export command: "Attempt to export '%s' which > is not visible via a prior import statement". Consider > that to recover from this error, most users would just copy the > export statement and change "ex" to "im". Might as well > just anticipate their recovery and cause the import. If the > import would cause an error, it will still be reported. > I can't think of how it could cause a change in behavior. > > Greg > > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Fri Sep 15 09:37:39 2006
This archive was generated by hypermail 2.1.8 : Fri Sep 15 2006 - 09:37:43 PDT