Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg From: rfg@NCD.COM (Ron Guilmette) Newsgroups: comp.std.c++ Subject: Re: "module" facility for top-level namespace control Keywords: namespace, module Message-ID: <5176@lupine.NCD.COM> Date: 21 Apr 91 23:53:21 GMT References: <1991Apr19.183922.1982@kodak.kodak.com> <5143@lupine.NCD.COM> <1991Apr21.014746.3526@kestrel.edu> Distribution: comp.std.c++ Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 108 In article <1991Apr21.014746.3526@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes: >In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: >>The problem is *not* one of establishing new "modules" or new "namespaces" >>(which class declarations can do quite well, thank you). > >Except that as you point out later on in your message, there is >currently no way to wrap a class declaration around a group of >top-level declarations and have them be treated as static members by >default... >> No. The problem >>is that if you do this, it becomes quite cumbersome to *reference* the >>things whose declarations you have now nested within class declarations. >>Specifically, it is quite irritating to have to write out the extra >>CLASSNAME:: qualification all over the place. >> >>How can this problem (i.e. the *real* problem) be solved? > >Though I'm not opposed to an attempt to solve this problem in some >such way as you suggest, I think you overrate it. OK. Perhaps I do. Let's agree that there are two problems here, namely: We need a feature (similar to classes) which will (by default) make any data member or function member `static' by default. (Note that all sorts of things like typdefs, enum types, struct types, union types, class types may now also be `members' of some containing class, but staticness/non-staticness is only an issue for the data members and function members.) We also need a related feature which would "open the scope" of such a "module" (within some other scope) so that (within that other scope) we don't have to deal with the tedium of writing CLASSNAME:: all of the time. Regarding the latter problem, I wrote: >>... it would probably be better to >>have something more like an Ada `use' statement to solve this problem. > >I agree that this would be handy. OK. One down. Now... about that first problem... given that we can nest groups of declarations in `class' declarations... >>... there would still be that irritating >>need to declare data and function members as `static'. That's where having >>a `module { ... }' construct would come in handy. We could >>define a `module' to be just like a class except that its data members and >>function members would all be *implicitly* static. Still, I'm sure that >>we're all against introducing new keywords if it could be avoided, so how >>about just using `class static { ... }' rather than requiring >>`module '. >Personally, I would prefer the introduction of a keyword in this case. I would prefer it myself, but remember that each tiny change of that sort causes the x3j16 membership to scream bloody murder. If we could convince x3j16 *just* that "default-static" classes and `use' statements were essential, I would say that we would have done a damn good day's work. It would be pushing our luck to imagine that we might also be successful in slipping in a new keyword to boot! >... Also, if there were also some sort of >`use' declaration, I think I would really want it to work only on >modules;... I disagree. >...otherwise its definition has to be that it makes the names of >only static members visible, because it wouldn't make sense to make >the names of normal (nonstatic) members visible... I don't see anything wrong with a generalized "opening of the scope" which applies to both static and non-static members. In some cases, it might actually be useful. For example: struct S { int data_member; void func_member (void); }; int S::*data_mbr_ptr; int S::*func_mbr_ptr; int i; void example () { use S; // scope opener i = S::data_member; // error - no object specified i = data_member; // error - no object specified S::func_member(); // error - no object specified func_member (); // error - no object specified data_mbr_ptr = &S::data_member; // OK data_mbr_ptr = &data_member; // also OK func_mbr_ptr = &S::func_member; // OK func_mbr_ptr = func_member; // also OK } -- // Ron ("Loose Cannon") Guilmette // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // New motto: If it ain't broke, try using a bigger hammer.