Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!nrl-cmf!ukma!rutgers!super.upenn.edu!eecae!fmsrl7!mibte!gamma!ulysses!faline!scherzo!allegra!alice!bs From: bs@alice.UUCP Newsgroups: comp.lang.c++ Subject: Re: Hey Bjarne! Some Questions Message-ID: <7682@alice.UUCP> Date: 10 Feb 88 17:34:48 GMT References: <1271@devvax.JPL.NASA.GOV> Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 192 Summary: A few answers - and more questions (des @ Jet Propulsion Laboratory, Pasadena CA.) writes: > Bjarne is coming to give a talk on C++ here at JPL on Friday the 12th, > and we get to grill him first in a round table discussion. Yes. Wouldn't it have been a better idea to grill me after? Well, you'll get to do that too. > Here are a > few questions I will be asking. I hope this gives Bjarne some warning, > and I hope everybody on the net can also discuss these issues rationally I take this to mean that you are also volunteering to summarize the answers here. > (am I dreaming? ;^) Yes. > 1) Exception Handling in C++ > a) How does/will it work? It doesn't. It is only in the ``thinking about'' stage. > b) What are the strengths and weaknesses of this approach? We need to get somewhat further to answer that one. Really, I wouldn't be happy to answer that one until I have had the opportunity to play with an implementation. > 2) OO Design Tools > a) Are there any? It seems that it has taken about 15 years > now for decent structured design tools to become available, > but now structured design is OBVIOUSLY obsolete ;^) Will > it take 15 years this time too? (I am NOT talking about > OO PROGRAMMING tools, but OO DESIGN tools) I don't know of any worthy of the name; and yes I think structured design is obsolete in the context of C++ because of (most) structured design deemphasizes types and lack ways of expressing inheritance. I have talked to people in the ``structured design'' community; they say that these problems are not fundamental and assure me that some structured design metod without these problems will emerge. I'd be most interested to see what that would look like. > b) What should such tools be like? How would they work, what > would they do? What are the hardest problems in OOD which > should be automated or supported byu such tools? I think you are surging ahead of the state of the art. The key question is still ``What is OOD?'' or even ``What should OOD be?'' There is work going on relating to encapsulations, specification, and expression of various forms of dependencies, and in tools for supporting particular ideas of how to support particular ``object- oriented'' languages, but - in my opinion - nothing you can point to saying ``THAT is OOD.'' > 3) The problem with (single) inheritance: Change the objects .vs. change > the tools. > > For example, in several articles and the book by Brad Cox, Please don't confuse me with Brad Cox or C++ with Objective C. > he demonstrates > how a new class of object can be manipulated by an existing tool without > changing the tool, just adding the new class definition for the object. > His example is a pencil cup which can really hold just about anything. > A method supported by the pencil cup is compute the weight of all items > in the pencil cup. In the "old fashioned" solution, there would be a > case statement with a case for each type ot item which could be held > by the cup. If a new class is to be supported, the case statement must > be altered to include a case for the new item. In the new fangled > OO approach, we just always ask the object for its weight, and Presto! > Chango! we don't have to change *anything* to support the new object. > > Gosh, that is wonderful. It takes only a few microseconds to notice the > dirt which is being swept under the carpet ... Yes. You might have put a battleship in the paper cup. Or more seriously put an object in a paper cup that does not know about weights. Or even worse put something in a paper cup that has a different notion of weight than you do. Nasty. It is, however, often very appropriate to distribute the code for doing a particular task (such as calculating weight) among the relevant classes rather than centralizing it in a single global function. The point is that when appropriate and when done well this minimizes the total number of dependencies in the system and eases modification and maintenance. In other words, data abstraction / object oriented programming sometimes leads to a cleaner decomposition of a system than does functional decomposition. > What this example REALLY shows is how OO systems can distribute the > responsibility for how a tool behaves from the tool maker to the > object developers. Each object must have all methods which may be > required by all tools in the system. Now when a tool is added, all > objects must change. What matters, I think, is what a ``tool'' is in this context, the magniture of the change, the locality of the change, and the ease with which the change is achieved. A system structured as a set of classes with explicit hierarchical relationships and programmed in a language that guarantees these relationships and the locality expressed in the design is often a big win. > See, the dirt is still there! > > I think that multiple inheritance is a reasonable solution to > preventing this distribution of responsibility. The tool implementor > would also implement a class which is manipulated by the tool. All > objects which can be manipulated then inherit the methods from this new > class. Flavors works something like this with mix-ins. > So the questions are: > a) Will C++ support multiple inheritance? It already does. The only snag is that getting it out of the lab/AT&T in the form of a new release takes time. > b) Given the existing lack of this capability, how does one > effect the same concentration of responsibility within > a project requiring a large number of tools? Given the answer to (a) you need to rephrase (b). However, C++ isn't Lisp (and Lisp isn't C++) so you should not expect MI in the context of C++ to have exactly the same properties (good and bad) as MI in the context of a particular Lisp dialect. It might also be worth mentioning that MI isn't a panacea either. For any MI scheme I can think of I can concoct a real example that allows me to say ``See, the dirt is still there!'' > 4) Complex Algorithms > > Object oriented design maps well into problem domains with a large number > of complex objects, but where the algorithm describing the interactions > of objects is simple. For example, say you are simulating a football team. > The players are naturally identified as objects. But what about the game > plan? This plan is very complex. How is the plan itself broken down into > objects, given the possibly extensive context dependancies of various > options within the game plan? "Pass if this and that and the other...." > > Note that structured design also falls down on complex context dependancies. > How does OOD help? Does OOD help? Object-oriented programming is no panacea, so it might not. Anyway, what is OOD? There is about as many definitions as there are people claiming to do OOD. There really isn't that many ways of coping with complexity. Roughly, you can find a fundamentally simpler way of performing a task or you can apply a divide and conquer strategy. The former approach ought to be language independent and any decent language ought to have the facilities for expressing the simpler solution - if it doesn't it may become inordinately hard even to think of the simpler solution. The latter approach requires ways for expressing locality/modularity and for expressing dependencies. OOD and OOP can help you IF there is a way of encapsulating part of a system so that it has a clean interface (hide the dirt - make it an implementation detail) and especially IF there is a hierarchial relationship between the concepts involved. Again, a nice modularized and hierarchically structured design may not be of much practical use if the language used for programming is such that the structure cannot be preserved; that is, if the structure exists in the documentation ONLY and the ``independent'' parts isn't really independent in the resulting code. > Anybody on the net with comments, please post them! I do not think > these are simple problems, and I do not think there is exactly one > sloution. I do want to see what Bjarne thinks about them and how C++ > supports the solution of these problems. I also want to see how the > net at large grapples with these problems. The proceeding of the USENIX C++ ``workshop'' is a major source of information on what I and others have been up to lately. Unfortunately, I haven't even received my copy yet. > Comment one and all! I'll second that.