ssimmons@convex.com (Steve Simmons) (07/13/90)
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? How did you solve it? We have come up with the following solutions. Other ideas will be appreciated. - Change X header files. It is truly a bug in X since they've tried protecting the namespace by prefixing everything with X or Xm. The problem is in integrating with future releases of X. - Change the NIH. They've never tried protecting the namespace and maybe they should. I've been leaning towards this solution by prefixing everything in the NIH library with "NIH". Upward integration is not as a necessary. NIH is stable. Also, there are minor nits within the NIH library that can be changed. - Isolate X and NIH code. Possible, however, it requires more dancing and does not solve the long term problem of the NIH's name space. Other possibilities... Thank you. Steve Simmons
jimad@microsoft.UUCP (Jim ADCOCK) (07/17/90)
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]
haynes@decwrl.dec.com (Charles Haynes) (07/17/90)
Jim Adcock from microsoft explains that one reason that names collide in libraries is: > 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. "Bunk" - to coin a phrase. I'm one of the people who chose to root the X toolkit widget heirarchy at "ObjectRec" (and this "Object"). I didn't do it out of hubris. I'm the same person who, with malice aforethought, called the basic user interface object a "Widget". We also chose to name our class objects "Class". Silly us, thinking that since that's what it was, that's what we should call it. In (C++) hindsight another mistake. We did it because we believed (and still believe) that a universal flat namespace for objects at the top level is braindead. We believed that given all the experience with modern structured languages that any reasonable new language would allow for selective and qualified importation and exportation of names. We never imagined that a modern lanaguage would require library writers to manually partition the namespace by appending or prepending bizarre and wonderful collections of letters to their names, praying that no other library developer had the same twisted sense of acronym choosing. We expected that name space scoping and import/export qualification was a well understood and desired thing. C++ has corrected many, if not most, of C's flaws. C has gradually shed many of its flat name spaces in favor of scoped or qualified naming schemes. We thought it would get them all. We were wrong. If I had it all to do over again I would have prefixed *all* of our names with Xt instead of just the routine names. Isn't hindsight wonderful? When we wrote the toolkit we had no idea which, if any object oriented language was going to win in Unixland. One thing we do agree on though. Single rooted container class libraries are a bad idea. Two points though: 1) The X Toolkit is NOT a container class library. 2) Just because the X Toolkit called it's root "Object" DOES NOT mean we thought it would be the root of everything. Quite the contrary. Go back and do your homework. Your ignorance of the X Toolkit is showing. -- Charles No disclaimer.