Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!ucsd!orion.cf.uci.edu!uci-ics!pompe.ics.uci.edu!schmidt
From: schmidt@pompe.ics.uci.edu (Doug Schmidt)
Newsgroups: comp.lang.c++
Subject: Re: static members
Message-ID: <4258@paris.ics.uci.edu>
Date: 16 Jan 89 04:32:40 GMT
References: <507@aber-cs.UUCP> <8770@alice.UUCP>
Sender: news@paris.ics.uci.edu
Reply-To: Doug Schmidt <schmidt@pompe.ics.uci.edu>
Distribution: eunet,world
Organization: University of California, Irvine - Dept of ICS
Lines: 103

In article <8770@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes:
[ a useful summary of new C++ features leading to increased data abstraction
  and more complete information hiding ]

Now that C++ provides more control over class data and function
members isn't it time to consider adding control over the visibility
of type declaration abstractions as well?  For example, whenever I
present the advantages of C++ to an Ada proponent, the discussion
inevitably turns to C++'s lack of proper nesting for type
declarations.  The Ada advocates claim that this makes it difficult to
control the name space of large programs, especially when combined
with the use of many header files and multiple programmers.

For example, it would be nice to be able to reuse the names of
auxiliary ``helper'' types within the same include file, e.g.:

----------------------------------------
// file search_structure.h

class Binary_Tree {
private:

   class Node { // node for a binary tree
   private:           
      int   Item;
      Node *Left;
      Node *Right;                      
   public:
      Node(int New_Item);
   };

public:
   Binary_Tree();
   Insert(int Item);
   Find(int Item);
};

class Linked_List {
private:

   class Node { // node for a linked list
      int   Item;
      Node *Next;
   };

public:
   Linked_List();
   Insert(int Item);
   Find(int Item);
};
----------------------------------------

   Now, I realize that for small examples like this, the proper choice
of names trivially disambiguates the different types and solves the
problem.  However, for very large programs, it requires a great deal
of effort to keep the type namespace from getting cluttered.  It would
be nice if the language supported this explicitly, rather than relying
upon individuals to keep track of the administrivia.

   I suppose one reason this isn't already implemented is due to the
fact that it might break existing C programs.  However, 

a). This has precedence, in that the proposed changes to the visibility of
    enumerated types declared inside structs and classes in C++ will
    break old C programs.  I'm specifically referring to Lippman and
    Moo's paper from 1988 C++ USENIX Workshop. 

b). It would be ashame not to permit this feature, since it seems
    orthogonal with the data and function abstraction mentioned
    previously.  

Perhaps a reasonable solution would overload the concept of ``static''
even further, allowing lexical (a.k.a. ``static'') structure and class
nestings by prepending the keyword static in front of the keywords,
like this:

----------------------------------------
class Binary_Tree {
private:

   static class Node { // only visible within the proper nesting level
   private:           
   public:
   };

public:
};
//.. same as before
----------------------------------------

Actually, cfront 1.2.1 already accepts this program (perhaps
erroneously!?!).  

Are there other problems with this scheme that I'm overlooking?

thanks, 

Doug Schmidt
--
schmidt@ics.uci.edu (ARPA) |   Per me si va nella citta' dolente.
office: (714) 856-4043     |   Per me si va nell'eterno dolore.
                           |   Per me si va tra la perduta gente.
                           |   Lasciate ogni speranza o voi ch'entrate.