Greg Jaxon wrote: > Well "local import Q::myInt;" seems odd if the default will be > local visibility for imports. Also "local export Q::myInt;" seems > self-contradictory. I don't think that "local import" is very useful and would be fine with making it illegal. In any case, the exact rules for interactions between "local" and "export" are certainly subject to a debate that I'd rather leave as a separate question. "local export" would not be valid -- "export" is not a package_or_generate_item_declaration in my proposal, it is a "package_item" itself so my suggested BNF change wouldn't apply to the package_export_declaration rule. Gord. > > Greg > > P.S. To me this argues for default public visibility (i.e. import == > export), > but as I understand it the committees hav already reached a compromise > to not do that. > > Gordon Vreugdenhil wrote: > >> >> >> Brad Pierce wrote: >> >>> The first option is the right way to go and doesn't look ugly to me. >> >> >> >> I should have been more careful in how I phrase that -- the first option >> isn't ugly but I don't want to have to dig through all the semantic >> implications on my own. The second option would be ugly. >> >> Does anyone have opinions on when "local" should NOT be permitted for >> the proposed change: >> [ local ] package_or_generate_item_declaration >> >> "local" might not make sense to me in the context of things that might >> not have names but I'm not sure if that can happen here given other >> semantic constraints. >> >> Gord. >> >>> -----Original Message----- >>> From: Gordon Vreugdenhil [mailto:gordonv@model.com] >>> Stuart Sutherland wrote: >>> >>> >>>> 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. >>> >>> >>> >>> >>> The grammar changes for allowing "local" to package declarations might >>> be a bit ugly. There are two choices -- the easy choice is to add >>> "local" as an optional qualifier in the package_item rule. Ie: >>> >>> package_item ::= >>> [ local ] package_or_generate_item_declaration >>> | anonymous_program >>> | timeunits_declaration >>> >>> Then we might have to have some semantic constraints that "local" >>> isn't legal for some constructs but I'm not sure if that is in fact the >>> case. >>> >>> The other option would be separate package_or_generate_item_declaration >>> into two parts -- one for packages and the other for generates. >>> >>> I am willing to add the former solution and a bit of text to what I am >>> writing up but I don't want this to snowball and I don't have the time >>> to try to figure out all of situations in which "local" on a >>> package_or_generate_item_declaration might not be reasonable. If people >>> are Ok with the simple change, fine, otherwise let's separate "local" >>> from export so that there can be more time for consideration. >>> >>> Gord. >>> >>> -- >>> -------------------------------------------------------------------- >>> Gordon Vreugdenhil 503-685-0808 >>> Model Technology (Mentor Graphics) gordonv@model.com >>> >>> >> > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Thu Sep 14 14:45:56 2006
This archive was generated by hypermail 2.1.8 : Thu Sep 14 2006 - 14:46:07 PDT