Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!bacchus.pa.dec.com!haynes From: haynes@decwrl.dec.com (Charles Haynes) Newsgroups: comp.lang.c++ Subject: Re: Namespace collision between X and NIH Message-ID: Date: 17 Jul 90 03:20:34 GMT References: <103894@convex.convex.com> <55847@microsoft.UUCP> Sender: news@wrl.dec.com (News) Distribution: comp Organization: DEC Palo Alto Lines: 57 In-Reply-To: jimad@microsoft.UUCP's message of 16 Jul 90 18:15:23 GMT 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.