Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bagate!dsinc!unix.cis.pitt.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnews!cbnewsm!gregk From: gregk@cbnewsm.att.com (gregory.p.kochanski) Newsgroups: comp.lang.c++ Subject: Re: namespace (rethought & reiterated) Keywords: New language construct Message-ID: <1991Feb4.231633.4164@cbnewsm.att.com> Date: 4 Feb 91 23:16:33 GMT References: Distribution: usa Organization: AT&T Bell Laboratories Lines: 38 In article uh311ae@sunmanager.lrz-muenchen.de (Henrik Klagges) writes: >Hello ! >Last year I proposed a change to the language that was quickly burned >to ashes. However, I still like it, so here it is again: > I say, treat files as objects. I think that in OOP you either 'should be > Say, 'test.cxx' wants to use stdio printf capabilities. To make an > unambigous include, it needs to say: 'I want a printf thing from stdio'. >#include >printf("Hello World !\n"); --or-- >#include >// BUT: >stdio::printf("Hello.\n"); > > In this case it is known that stdio is included (so a name like stdio::* > can be resolved). If I want to use printf, I have to precede it with the ^^^^^^^^ > stdio::printf. In standard c/c++ the resolving would search the complete > include/link tree - with all the nasty consequences. Well, first, forcing the use of this feature would break all C and C++ code in the universe. I don't think that that is desireable. Compilers would presumeably be forced to add more decoration to a function name '5stdio5printfFe' or something like that, but that's O.K. It seems a little sloppy to use the function name -- you might run into various operating-system-dependent obscurities (like MS-DOS doesn't know about small letters). Declaring the name of a module with some statement might be better, perhaps extern "C++::modulename" { module here } or something that isn't yet used. This would also keep the seperation between the preprocessor and the compiler intact. I like the idea, but don't think that I'm an authority.