Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!sol.ctr.columbia.edu!ucselx!ucsd!ucbvax!pasteur!dog.ee.lbl.gov!ux5.lbl.gov!beard From: beard@ux5.lbl.gov (Patrick C Beard) Newsgroups: comp.std.c++ Subject: Re: "module" facility for top-level namespace control Message-ID: <12718@dog.ee.lbl.gov> Date: 2 May 91 06:27:19 GMT References: <1991Apr25.060721.12694@alias.com> <1991Apr29.174033.29627@alias.com> Reply-To: beard@ux5.lbl.gov (Patrick C Beard) Distribution: comp.std.c++ Organization: Berkeley Systems, Inc. Lines: 26 X-Local-Date: Wed, 1 May 91 23:27:19 PDT In article <1991Apr29.174033.29627@alias.com> rae@alias.com (Reid Ellis) writes: #Why don't we simply use a syntax which already evokes this concept -- #using "extern"? # #I don't know if another keyword after the extern is necessary, or #simply the name of the enclosing scope. Something like the following? # #extern NIH { ##include #}; This syntax was created for specifying language specific linkage for linking to C, FORTRAN, Pascal, etc. And currently it requires a set of quotes around the keyword after extern. I don't think that the namespace usage is really in the spirit of linkage specification. I believe that we have everything we need by allowing nested class declarations and enumerations within a class. My only problem so far has been with the fact that the tag type names from nested enums and classes are visible in the global namespace. This has been ammended I believe in compilers that are based on CFront 2.1. Correct me if I am wrong. -- // Patrick C. Beard, Software Engineer, Berkeley Systems, Inc. // "Heroes of technology." // beard@lbl.gov, d0346@applelink.apple.com (ATTN: Patrick)