Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Namespace collision between X and NIH
Message-ID: <55847@microsoft.UUCP>
Date: 16 Jul 90 18:15:23 GMT
References: <103894@convex.convex.com>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: comp
Organization: Microsoft Corp., Redmond WA
Lines: 39

In article <103894@convex.convex.com> ssimmons@convex.com (Steve Simmons) writes:
>
>	We have run into the following name space collision with the 
>	following two packages, X11 and NIH.  Both use the identifier
>	Object. X11 uses it as a typedef to a pointer to the ObjectRec
>	and NIH uses it as a base class.
>
>	Has anyone else run into this problem?  

I think there are two separate problems here worth stating:

1) C++ really doesn't provide a good, clean universal way of handling naming
   collision between libraries.  The reason is presumably because standard 
   linkers are being used to compile the language.  So, compile a class
   "Object", and the name "Object" is attached to all methods of that class,
   so that the standard "C" linker can do part of the type checking,  Thus,
   given two compiler libraries from two vendors, each with a base class 
   "Object", you're SOL.  Some other OOPLs give one a chance to rename 
   inheritence hierarchies to avoid this problem.  But, even with renaming 
   options, writing programs using multiple class hierarchies can be very 
   troublesome.

2) Class library developer hubris.  When a set of class libraries are named
   with a base class "Object," the intent is clearly programmers should
   only use that class library, that library's concept of what a base object
   is is "universal", and thou shalt use no other class library.  Which I 
   say is bunk.  People should be able to use libraries from multiple 
   sources simultaneously, if to do so helps them meet their goals.  In 
   order for this to happen, class writers must not assume they have created
   the universally applicable answer to what an "Object" base class must be,
   but rather only one answer of what an "Object" should be for some 
   domain of applicability.  For example, if one were writing a set of classes
   for signal processing vectors of numbers, perhaps "SPObject", or something,
   might be a good name, rather than the universal nomiker "Object."  This
   is not only true of the "Object" word.  No one should try to usurp 
   and abuse any of the commonly used, simple words that programmers need 
   to describe things.

[standard disclaimer]