Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!hplabs!otter.hpl.hp.com!otter!scu
From: scu@otter.hpl.hp.com (Shankar Unni)
Newsgroups: comp.lang.c++
Subject: Re: namespace (rethought & reiterated)
Message-ID: <2620020@otter.hpl.hp.com>
Date: 1 Mar 91 12:00:17 GMT
References: <uh311ae.665663860@sunmanager>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 71

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. Therefore it 
>    is not enough to know that ' a name is external ' or ' thank god that it
>    is somewhere up the include tree '. If it is known that a name is not de-
>    fined within a file object, it must be possible to establish a single link
>    to that name (which is within another file object), otherwise the rigid 
>    OO environment breaks down. This could be accomplished in a Modula2/3-     
>    fashion:

> 3. Example:

> #include <stdio.h::printf>
> printf("Hello World !\n");

>    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");

After the last homily, I'll address this feature. This looks like an
interesting extension to the language, well in the vein of the existing
functionality.

Some of the objections ("breaks existing code") can be easily countered by
providing that if there is only one definition of a symbol, then module
qualification is not required:

  #include <stdio.h>
  printf ("hello\n");	// if this is the only declared or imported printf.

We thus cover (d) quite adequately. Now for (a), (b) and (c).

Someone (I'm *not* volunteering :-) needs to implement this feature,
preferably in gcc/g++, and try it out. How about using it on, say, the NIH
library (which does declare an "Object"), and something else which does the
same? 

One would have to tweak NIH a little: "class Foobar : NIH::Object { .. };"

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.
-----
Shankar Unni                                   E-Mail: 
Hewlett-Packard Laboratories, Bristol        Internet: shankar@cup.hp.com
Phone : +44-272-799910 x24284                    UUCP: ...!hplabs!hpda!shankar