Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!snorkelwacker.mit.edu!ira.uka.de!fauern!NewsServ!sunmanager!uh311ae
From: uh311ae@sunmanager.lrz-muenchen.de (Henrik Klagges)
Newsgroups: comp.lang.c++
Subject: namespace (rethought & reiterated)
Summary: Treat files as name objects
Keywords: New language construct
Message-ID: <uh311ae.665663860@sunmanager>
Date: 4 Feb 91 10:37:40 GMT
Sender: news@NewsServ.Informatik.TU-Muenchen.DE
Organization: Technische Universitaet Muenchen, Germany
Lines: 63

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:
1. the problem:
- 'that stupid programmer used 'object' as the name of his root thing in
   his tree class lib. Now I (the intelligent programmer) can't use that
   name ('object') anymore, if I still want to use the other lib.'
- 'I got that big chunk of PD source and tried to compile it. Now, the
   linker doesn't find _unknown_function_number_zillion+1. I know which
   file calls it, but it just includes a glob.h header fanning out into
   100 directions so that I could not trace the name down to the file where
   it actually should be defined.
   I grepped /usr/include, /usr/include/sys & bsd, *lib*, /*/local/* ---
   and finally made a low-level byte pattern search of the mounted discs to
   find the headers & libraries.'

2. A proposal:               
   I say, treat files as objects. I think that in OOP you either 'should be
   able to know *exactly*' OR 'shouldn't need to know'. You should never
   'need to know, but hell, how, where, if ...'. 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:
   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'. It
   is not enough to say: 'I want stdio' or ' I want printf '. Printf is a 
   'structural subobject' of the 'structural object' stdio.h (while e.g. a
   'real number' would be a logical or functional subobject of a base class
   'number). OK. So test.cxx says: 

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

   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.

4. Problems
   In case of interference with the overload mechanism, the explicit refe-  
   rence (stdio::printf) has to be used. 

Comments, flames, workarounds, etc. please.
Thank you.

Cheers ! Rick@vee.lrz-muenchen.de
(also uh33201@dm0lrz01.bitnet, uh33201@ymp.lrz-muenchen.de, uh311ae@sun7.l*
 Compuserve: 100014,353)