des@jplpro.JPL.NASA.GOV (David Smyth) (02/10/88)
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. 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 (am I dreaming? ;^) 1) Exception Handling in C++ a) How does/will it work? b) What are the strengths and weaknesses of this approach? 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) 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? 3) The problem with (single) inheritance: Change the objects .vs. change the tools. For example, in several articles and the book by Brad Cox, 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 ... 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. 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? 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? 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? 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. Comment one and all!
bs@alice.UUCP (02/11/88)
(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.
jima@hplsla.HP.COM ( Jim Adcock) (02/17/88)
OK, here's some comments per your requestsz; 1) Exception Handling in C++ I consider this an interesting topic. I've heard several authors claim they have ways of doing this, but I've yet to get my hands on a paper. So far the only big weaknesses I've been able to find in trying to apply C++ to "real world" problems [as oppose to acedemic research, G-Jobs, etc] are 1) lack of try/recover 2) incomplete set of tools [debuggers, profilers ....] due to the relative immaturity of the language 3) memory management of SOME parculiar objects, but maybe multiple inheritence can solve these problems. 2) OO Design Tools a) Are there any? b) What should such tools be like? From MY point of view the biggest step forward in the "Design Tools" area is the arrival of a language that will allow me satisfactory expression of my design in pretty much the form I conceive it. And when written have the design execute in a reasonable amount of time, WITHOUT having to hack on the underlying machine representation of the language. A GREAT compiler for a GREAT language represents the BIGGEST win in this area as far as I'm concerned. 3) The problem with (single) inheritance: Change the objects .vs. change the tools. I view C++ as primarily a tool-making tool, where most of the tools are going to be expressed in the form of C++ Classes. Then, when you have the full set of tools [C++ classes] built up necessary to do YOUR job, your job becomes relatively easy, because you have the tools necessary to do your job. At least for the kind of stuff I need to do C++ is a VERY GOOD tool-making tool. The times that my software-programming-life has become VERY difficult has been when someone CLAIMS to have a complete set of tools to do MY job, and then forces me to use those tools .... I would be VERY wary of anyone who claims to have all tools necessary to do YOUR job, and asks you to relinquish control over making the fundamental tools necesary to do YOUR job. I view multiple inheritence as a two edged sword. I am anxiously awaiting this feature in [released versions] of C++ because 1) I believe many classes are very similar except for small pieces that need to be spliced in or out. Choice of memory management scheme is one example I believe might need to be spliced in/out of many C++ classes. 2) I believe there is a need to "glue" together a variety of fundamental, "simple", -- but hard to get "perfect" capabilities. For example, maybe there is a need to glue linked-list capabilities onto an existing class. Sure I can come up with a linked-list capability -- but couldn't it be possible that I might be able to pick a better capability off the shelf? [In any case, the ultimate decision of which approach to take would be MINE] The other edge of the sword is that I am VERY nervous about how my COMPATRIOTS might missuse this feature :V) 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...." I DO believe that C++ would probably be missused if it was used for A.I. -type applications like your "football game" appears to be. [Then again, how important are "REALLY COMPLICATED" solutions to the real world? I tend to believe simple, well thought out solutions make a bigger contribution to the real world ... but enuf philosophy..] For this stuff use an A.I. language like Lisp. Unfortunately, Lisp is looking kindof dated from this not-much-Lisp user's eyes. It might be nice if you could mix-and-match capabilities from C++ and Lisp cleanly ..... Unfortunately I think using Lisp is going to require a LARGE runtime support, isn't it ???
craig@unicus.UUCP (Craig D. Hubley) (02/25/88)
> > 2) OO Design Tools > > a) Are there any? It seems that it has taken about 15 years > > ... > 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. The only `OO Design tool' currently in use that `object people' might recognize as such would be a prototype, written in an O-O language, perhaps on top of a Lisp dialect, that at least `stubs' the functions required, and specifies the inheritance lattice, etc. Modifications to the detailed design specification can then be carried out on this dynamic model rather than the more static compiled implementation, defining the static inheritance lattice only from the stabilized prototype, whose original hacked-up code should always be burned to beyond reconstruction. This is, of course, just rapid prototyping, which is always appropriate to attack ill-defined problems. And the further we go, the more ill-defined the problems seem to get... > > 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. I hope it comes soon. There are *some* people that think that object languages without multiple inheritance are nothing but a harmful nuisance that encourages people to hide dependencies under a `modular' structure, since the explicit mechanism is inadequate to express complex relationships. At the very least, a language lacking such tools should allow access to conventional modules (that is, functions) to keep the mess to a minimum. Thankfully, C++ and the various Lisp object languages all do this, though I don't know if Smalltalk does... > > 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? Carefully, and documenting yourself well... > 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!'' What about the MI scheme used in LOOPS, that specifies a fixed order of executing super (that is, inherited) methods, and allows the method to call on its super-methods explicitly, or specify the order in the class description ? The only dirt that I ever found in that was that sometimes a subclass would have to explicitly call on its supers by name, but since it relied heavily on specific inheritances anyway... If a specialized method requires a substantially different order of execution than its unspecialized parent, argument could be made for it being a different method in disguise... all the same, LOOPS could do it, and I would like to know where the dirt was hiding... ? (Aha! There it is, in the LISP!!! ---> (()()(((*)()):-)))(())) > > 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...." It might be more appropriate to say that it maps easily into such domains, and with more difficulty into those with more complex interactions. But Kay's Maxim `Simple things should be simple. Difficult things should be possible.', still holds. Object languages are, as Bjarne says, no panacea. With that in mind: Perhaps a game plan is an explicit & active context. This is a fertile ground for multiple inheritance. Imagine that each player has his own strengths and weaknesses, but that his `intelligent' methods evaluate the situation based upon methods and variables inherited from the game plan currently used. That is, his `Pass' method calls `HoldOn?' and `WhoTo?', both of which are inherited from the game plan. In this case, GamePlan.HoldOn must consult it's `view of the world' to see if it is desirable that that particular player holds onto the ball. If not, it says `No', and GamePlan.WhoTo provides a list of players, in order of desirability, to whom the ball should be passed. The player then consults his own view of the field to decide who is the most likely candidate for a pass, possibly calling on HoldOn and WhoTo again as the situation changes. Different game plans can be substituted without affecting this procedure, or interposing artificial classes between Player and its subclass Linebacker, for instance. Just a thought. Think about doing it *without* MI, though... > > Note that structured design also falls down on complex context dependancies. > > How does OOD help? > ... > 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. I have always thought of Object design as the logical next step after Structured design. In the latter, we specify a hierarchical *functional* relationship, keeping functions and data structures as modular as possible. In the former, we specify a hierarchical relationship for *function AND data*, recognizing their fundamental interconnections and making them explicit, making it *easier* to keep function and data structures as modular as possible, with the added benefit of a more flexible interface that more adequately expresses how people think of problems. A big win, overall. > 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 Pretty much anything can be *characterized* with a hierarchical structure, whether that structure is functionally meaningful or not is another matter... talk to an anthropologist about this one... > > Comment one and all! > I'll second that. Done (the one, anyway). Craig Hubley, Unicus Corporation, Toronto, Ont. craig@Unicus.COM (Internet) {uunet!mnetor, utzoo!utcsri}!unicus!craig (dumb uucp) mnetor!unicus!craig@uunet.uu.net (dumb arpa)
bertrand@hub.ucsb.edu (Bertrand Meyer) (02/29/88)
Writing a note about another object-oriented language in the C++ newsgroup will probably anger some (although mentions of Objective-C are apparently not infrequent). To anybody who will resent this message, I apologize. But ignorance of the Eiffel solutions seems so pervasive that I believe it to be a service to your community (beyond any self-serving purpose that will be seen in this move) to draw your attention to them. Intervening here too often would clearly be improper, so I would urge anybody who wants to converse with me to use mail rather than postnews. I have often had trouble with outgoing mail, so if you don't get a reply from me send me your message again with your Post Office address. FAX (number below) is also OK. Clearly there will be an Eiffel newsgroup anyway someday. (Anyone interested may contact me.) The object of this intrusion is actually stated quite briefly: although I browse only occasionally through network news in general and the C++ newsgroup in particular, I am puzzled each time to see how the C++ community seems to be chasing after solutions to problems we settled long ago with Eiffel. Take multiple inheritance, for example: it has been there from the beginning, and done I believe quite cleanly (see e.g. the solution to the name clash issue etc.). Or include files: there is none (repeat, none) in Eiffel, and no global variables either: all inter-class relationships are managed automatically by the environment. And exceptions (the most recent addition): they are clean, simple, and based on a comprehensive theory of software correctness. Enough. Those who have read so far and want to know more can get literature from me. By the way, we are a commercial organization (so what? AT&T is not a philantropic society), founded by scientists who believe enough in the soundness of what they do to have put their careers on the line. Bertrand Meyer Interactive Software Engineering Inc. 270 Storke Road Suite 7 - Goleta CA 93117 Telephone (805) 685-1006 - FAX (805) 685-6869 Europe: Societe des Outils du Logiciel Centre d'Affaires 3MPP, 4 rue Rene Barthelemy 92120 Montrouge France Telephone (+33/1-46 57 13 36, FAX +33/1-46 57 01 03)