Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!otter.hpl.hp.com!otter!scu From: scu@otter.hpl.hp.com (Shankar Unni) Newsgroups: comp.lang.c++ Subject: Re: namespace (rethought & reiterated) Message-ID: <2620019@otter.hpl.hp.com> Date: 1 Mar 91 11:48:05 GMT References: Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 87 In comp.lang.c++, horstman@mathcs.sjsu.edu (Cay Horstmann) writes: > >In article <1991Feb6.155227.553@mathcs.sjsu.edu> horstman@mathcs.sjsu.edu (Cay Horstmann) writes: > >>I for one wish that the ANSI C++ committee had the courage to address > >>these issues and do these cleanups [I have lots more to suggest] once > >>and for all, no matter how much C code they break. > >> > >> the mantra "it will break gobs of old code" can ... frustrate discussion. > > I am not sure how wise it is to turn to C++ TODAY if one is unwilling to > live with a changing language. > I had to do LOTS of reworking with "extern C" when type-safe linkage came out. > I still have some "assignments to this" in some old code and expect to have to > redo them when my next compiler won't support them anymore. > That is just fine with me. I know C++ is currently an evolving language > and I know what I am getting into by using it now. I can understand the frustration of those who would like to see a lot of language ills corrected, when we (apparently) have a chance to do so in the ANSI committee, rather than have to wait and invent yet another language later. Still, there should be a sense of balance when introducing brand new features into the language. The ANSI C committee tried very hard to only introduce things that had already been experimented with (with one gruesome exception: trigraphs, which should stand as a banner example of the sort of things that get created by committee). It's very important to gain "prior expertise" before deciding on a standard form of it: (a) Is it possible, and preferably, easy to implement? (b) Are its semantics well understood (esp. corner cases and interaction with the rest of the features of the language)? (c) Do we have sufficient programming expertise with it? (d) Does it gratuitously break existing code? (e) Is it *really* necessary? Each of these criteria is important in its own way. The first two are obvious, and it is clear that no answer to them can be provided without first implementing the feature in some experimental compiler (usually gcc/g++, or its likes). Once all the potential problems are ironed out, we come to criterion (c). Is this the correct answer to the problem we are trying to solve? Is there a "better" way of achieving it? This may mean mean several passes over the feature until it is "neat" and "compact", and fits in with the rest of the language. (This is where a lot of the subjective judgement comes in. We try not to introduce too many new keywords, or unnecessary syntactic sugar, and try to meld it into the existing language.) Criterion (d) is the sticking point mentioned previously. Admittedly, C++ is an evolving language. However, for people to gain *real* expertise in the language, it must be quasi-stable (i.e. not frozen, but at least of a jelly-like consistency :-), or "commercial" (read: "real") customers won't be willing to touch it. Finally, criterion (e) has also been invoked several times. The idea here is to prevent C++ from becoming the PL/I (or Ada) of the 90s. The "kitchen sink" principle is attractive to many academics, but it becomes impractical in the real world, where people have to: - write compilers. - be trained in the language - a language that is too big has too steep a learning curve. - write code using the language - if the features are ill-thought-out, there is a real problem in choosing the right feature-set to implement programs in. - read and understand other peoples' code - see point 2 above. Thus, a feature should be added or modified only if it is seen to cover an important piece of missing functionality, and there is no easy way to achieve the same using some combination of existing functionality. There are several conflicting forces acting on the committee, and they have to be very picky in selecting and modifying features, if they are not to create a monster. ("Two-headed dinosaur created in lab!"). ----- Shankar Unni E-Mail: Hewlett-Packard Laboratories, Bristol Internet: shankar@cup.hp.com Phone : +44-272-799910 x24284 UUCP: ...!hplabs!hpda!shankar P.S. The current exception-handling debates in the committee should be an interesting test of the criteria above. I believe several committee members are rushing ahead to implement this feature in order to gain expertise with it.