Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!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: <5281@lupine.NCD.COM> Date: 27 Apr 91 01:41:06 GMT References: <1991Apr19.183922.1982@kodak.kodak.com> <5143@lupine.NCD.COM> <1358@appli.se> Distribution: comp.std.c++ Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 129 In article <1358@appli.se> niklas@appli.se (Niklas Hallqvist) writes: >rfg@NCD.COM (Ron Guilmette) writes: > >:In article <1991Apr19.183922.1982@kodak.kodak.com> cok@islsun.Kodak.COM (David Cok) writes: > >I've thought about this, and come to the same conclusions as Ron. >Well, how should the "use" syntax look like? How about: > >default class CLASSNAME-LIST { > // code goes here; >} > >This way, we won't need to introduce new keywords. Possibly the >"class" keyword could be left out but I think it makes the code >more readable... >... Should we (the net) try to write a proposal >to the ANSI commitee before their june meeting in Lund, Sweden (at >least I think that's the case, some of the members will speak at >some seminars there, which I'll try to attend). Sure. Why not? I think that the x3j16 committee (and especially the libraries working group) would probably thank us for it. Let me see if I can get the ball rolling a bit (and see where it goes). First off, I must say that I think that the proposal should be entirely non-committal about the specific syntax and keywords used. We know what our *real* goal is right? We want a specific *feature*. None of us is going to die if the keywords which must be used to code an instance of that feature are something other than what we would prefer. I think that most of us can manage to adapt to whatever keywords x3j16 likes best, as long as we get the *feature*. Arguing for a specific keyword (or set of keywords) is only likely to turn-off some members of x3j16, so why not just propose the feature and ask x3j16 to decide what keywords they want to use to express it? Here are some of the possibilities: module { ... }; package { ... }; default class { ... }; class static { ... }; Let's not argue about that. Let's just pick some convenient "stand-in" for the syntax/keywords (just for now) and let argue instead about the important rules that should apply to this general "feature". For the sake of example (only) I'll use a (hypothetical) new keyword, i.e. "package" and I'll assume that the real choice will be left to x3j16. Now. What are the rules applicable to this feature? Well, I can think of a few right away: The name of a "package" is (in general) treated like a class name, except that you are not allowed to declared objects of a "package"... i.e. the following is illegal: package foobar { ... } object; as is: package foobar { ... }; foobar object; You are not allowed to take the address of a "package". (That's only logical, since the only name that you have for it acts mostly like a class name anyway, and it's likewise nonsensical to take the address of a class name.) Also, there are no pointers to packages, references to packages, or pointers to members of packages. All data and function members of a "package" are implicitly "static". They may also be *explicitly* declared to be "static", but in such cases, there must be a definition of the given member somewhere (later) within the same compilation unit, and these definitions will be given "static linkage" by the compiler. Function members of packages may never be declared to be virtual. Since there are no references to packages (and since they would nonsensical anyway) packages DO NOT automatically have copy constructors or assignment operators implicitly generated for them (by the compiler). (Each package does however get a default constructor generated automatically for it by the compiler if one is not explicitly provided.) A package may have a constructor and a destructor. If provided, the constructor and destructor act just like static member functions (i.e. they have no `this' pointer). If provided, a package constructor must take no arguments, and this constructor will be automatically invoked once (before main() is entered). It is never invoked otherwise (not even during the construction of an object of some class type whose type inherits from the package). If provided, a package destructor is invoked once (after main() is exited). It is never invoked otherwise (not even during the destruction of an object of some class type whose type inherits from the package). In all other respects, "packages" act like classes. In particular, package declarations may be nested within functions, within class declarations, or within other package declarations. Likewise, classes, packages, and function declarations and definitions may be nested within packages. Furthermore, packages are treated just like classes when it comes to inheritance. You can inherit from a package and a package can itself inherit (from either a class or from another package). The "public", "private" and "protected" specifiers have all of the same meanings for packages as they do for classes. Since data and function members of packages are always static, taking the address of a member of a package yields a pointer to an object or a pointer to a function (respectively) just as would be the case for static members of class types. Did I miss anything? Oh yes... separately (by attached to this same proposal) there must ultimately be a description of the proposed "use" statement (if people agree that such a thing would be needed in case we got "packages"). I don't have time to write that up today, though. -- // Ron ("Loose Cannon") Guilmette // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // New motto: If it ain't broke, try using a bigger hammer.