Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!chalmers.se!appli!niklas From: niklas@appli.se (Niklas Hallqvist) Newsgroups: comp.std.c++ Subject: Re: "module" facility for top-level namespace control Keywords: namespace, module Message-ID: <1358@appli.se> Date: 21 Apr 91 13:27:35 GMT References: <1991Apr19.163253.22253@kestrel.edu> <1991Apr19.183922.1982@kodak.kodak.com> <5143@lupine.NCD.COM> Distribution: comp.std.c++ Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN Lines: 98 rfg@NCD.COM (Ron Guilmette) writes: :In article <1991Apr19.183922.1982@kodak.kodak.com> cok@islsun.Kodak.COM (David Cok) writes: :>In article <1991Apr19.163253.22253@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes: :>> :>>To see if we can get some discussion going on the matter, let me :>>sketch a simple proposal. Suppose we were to introduce a keyword :>>"module" with a simple syntax: :>> :>> module Foo { :>> // ... declarations :>> } :>> :... :> :>Would it work just as well to say :>class Foo { :>#include "something.h" :>} :> :>since classes and everything else (?) can -- eventually -- be nested inside :>classes. :Right. That's just what I proposed awhile back. However I think that Scott :wanted something slightly more than this (and so do I). :It is (or will be in future) reasonably easy to package up all of the things :that we now put into include files and give them all their own little :namespaces by wrapping them in `class { ... }'. (Note that :you will have to declare all data member and function member as "static" :if you want the effect of a "module" however.) :The problem is *not* one of establishing new "modules" or new "namespaces" :(which class declarations can do quite well, thank you). 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? :Recently, I proposed the introduction of a Pascal style `with' statement. :Thinking more about it, I now realize that it would probably be better to :have something more like an Ada `use' statement to solve this problem. :An Ada `use' statement looks just like `use ;' (where :is just an identifier for some module). You put such a statement into :any scope where you want to be able to refer to the members of :*without* the qualification. (The `use' statement only applies within :the scope which contains it.) If you `use' two or more modules within :the same scope, and if those modules contain identically named declarations :for different things, then in order to refer (unambigously) to any of the :things with the (conflicting) name, you must use the full and explicit :qualification. :The big problem with a Pascal-style `with' statement is that it is treated :as a form of an executable statement (rather like a `while' statement). :Thus, you can't place them at `file-scope' in C++. :But Ada's `use' statement is treated like a declarative statement. Thus, :if we had such a beast in C++, we could make it legal to write `use' :statements at the file-scope level. That could be most helpful. :I think that if we had a `use' statement in C++, the problem of namespaces :would be mostly solved. Of course 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 '. 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. The effect of such a statement would be to push the scopes of the specified classes, much like the effect of entering the scope of a class who publicly inherits from those classes. The last point made is relevant to compiler implementors who could reuse the scope-handling in these cases. Would anybody care to comment on this? 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). Niklas -- Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!sunic!chalmers!appli!niklas