Path: utzoo!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.lang.c++
Subject: Re: namespace (rethought & reiterated)
Message-ID: <4196@lupine.NCD.COM>
Date: 2 Mar 91 21:11:20 GMT
References: <uh311ae.665663860@sunmanager> <2620020@otter.hpl.hp.com>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 134

In article <2620020@otter.hpl.hp.com> scu@otter.hpl.hp.com (Shankar Unni) writes:
+In comp.lang.c++, uh311ae@sunmanager.lrz-muenchen.de (Henrik Klagges) writes:
+
+> 2. A proposal:               
+>    I say, treat files as objects. [...] This means, if I use a name
+>    in a file, it must be resolvable without any ambiguity...
...
+> 3. Example:
+
+> #include <stdio.h::printf>
+> printf("Hello World !\n");

This is not a great example, because Henrik should be using C++ streams
instead of the crusty old C I/O routines. Still, we get Henrik's point.

+>    In this case it is clear what printf means - because it has been explicitly
+>    included as *the* printf. If I want to include more things from stdio, it 
+>    could be to much work to include them all in this way. Therefore, as in
+>    Modula, simply say:
+
+> #include <stdio.h>    
+> // BUT:
+> stdio::printf("Hello.\n");
...
+But then, one is also forced to ask the question (e). Is this any better
+than if Keith G. had originally written:
+
+  class NIHObject { };
+  class Foobar: NIHObject { };
+
+I.e. instead of a syntactic module qualification, just prepend some unique
+prefix?
+
+I can't think of anything addressed by this proposal that could not have
+been just as easily solved by the above technique. Does the feature provide
+for the user to randomly throw in libraries, and have "DWIM" qualifications
+take place? I think not: he would have to edit all the files and add the
+qualifications regardless. Even if some implicit qualification is allowed,
+he would still have to qualify everything for safety. How is this different
+from just using more unambiguous and unique names?
+
+I would, thus, at first glance, vote NO on this feature. But if someone can
+implement this and convince me as to how it solves this (admittedly
+important) problem in a novel way that is much easier and cleaner than
+existing technology, I might go for it.

Namespace pollution is indeed an important and, I believe, an unsolved
problem in C++.

The idea proposed here is to use include files as individual namespace
"modules".  That's not a bad idea, however C++ already has something
which can serve pretty well as a namespace "module".  It's called a
class.  Consider a header file like:

	incl.h:
	--------------------------------------------------------------------
	extern int somedata;

	typedef double* double_p_type;

	extern void myfunc (double, char);
	--------------------------------------------------------------------

Ask yourself if there are any reasons why this could not be rephrased as:

	incl.h:
	--------------------------------------------------------------------
	class incl {
	public:
		static int somedata;

		typedef double* double_p_type;

		static void myfunc (double, char);
	};
	--------------------------------------------------------------------

Now if we include this into some other file (or files) we should be able
to refer to `incl::somedata', `incl::double_p_type', and `incl::myfunc'.

Presto!  No more namespace pollution problems.  Right?  Well... not quite.

The problem with this scheme is that we are now *forced* to *always*
provide explicit qualification for anything we get from `incl.h'.  If
you are lazy (like me) this will seem to be a large and unnecessary hassle.

For example, I might have to write:

	--------------------------------------------------------------------
	#include <incl.h>

	double d;

	void foobar ()
	{
		incl::double_p_type dp = &d;

		incl::myfunc (dp, (char) incl::somedata);
	}
	--------------------------------------------------------------------

Is there a solution?  Sure.  We could introduce a `with' statement (as in
Pascal) which could specify that within a given region, a particular class
type should be used for implicit qualification (when necessary), e.g.:

	--------------------------------------------------------------------
	#include <incl.h>

	double d;

	void foobar ()
	{
	    with (incl)
	    {
		double_p_type dp = &d;

		myfunc (dp, (char) somedata);
	    }
	}
	--------------------------------------------------------------------

In the example here, the thing mentioned in the "qualifier" clause of
the `with' statement is a type (rather than an object designator, as in
Pascal).  Actually, I can see the usefulness of *both* possible forms
of `with' statements in C++ (i.e. `with' statements specifying types
and `with' statements specifying particular objects).  Both forms
could lead to less verbose C++ programs.  (I'm not really sure if that's
an argument in favor of `with' statements or against them. :-)

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// New motto:  If it ain't broke, try using a bigger hammer.