Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!tektronix!sequent!mntgfx!plogan From: plogan@mntgfx.mentor.com (Patrick Logan) Newsgroups: comp.lang.c++ Subject: Re: Smalltalk-80 like inheritance in C++ possible ? Message-ID: <1989Mar28.091305.920@mntgfx.mentor.com> Date: 28 Mar 89 17:13:04 GMT References: <110@honold.UUCP> <5481@rlvd.UUCP> <1411@sw1e.UUCP> <9174@claris.com> <1421@sw1e.UUCP> <1335@blake.acs.washington.edu> <7431@thorin.cs.unc.edu> Organization: Mentor Graphics Corporation, Beaverton Oregon Lines: 94 In-reply-to: coggins@coggins.cs.unc.edu's message of 27 Mar 89 15:08:24 GMT In article <7431@thorin.cs.unc.edu> coggins@coggins.cs.unc.edu (Dr. James Coggins) writes: => In article <1335@blake.acs.washington.edu> keffer@blake.acs.washington.edu (Thomas Keffer) writes: => >What to do? It seems to me there are 6 main _PRACTICAL_ problems now => >1) Poor quality compilers. You never know if it's you or cfront. => >2) Few gurus. => >3) Few "known correct" examples of non-trivial code. => >4) Only two books, neither of them very good. => >5) Few precanned, bulletproof classes. => >6) Steep learning curve, especially to learn writing new classes. => => ... => => Nevertheless, I am preparing to release my C++ class library next => month, which you will find to be "in regular use, believed mostly => correct, highly nontrivial code". And apparently written in an idiom => that does not encounter many of the difficulties I keep reading about => in this newsgroup. (When people have come to me asking about how to do => some weird thing in C++ I usually have found there to be fundamental => design idiocies. Correcting them made the weird thing unnecessary.) These weird tendencies can be attributed in part to the lack of good material explaining how to use C++ effectively. As Dr. Coggins indicates, better material should become available as experience is gained and C++ becomes less of a moving target. However, the language design contributes to the problem as previous posters have mentioned. Its mechanisms are non-orthogonal (e.g. using constructors with arrays of objects), non-perspicuous (e.g. a data member attributed with the keyword 'static' means that member is a class variable rather than an instance variable), and complicated (e.g. no automatic garbage collection). I know there are reasons for the language being the way it is and I accept them. (So no flames, please.) But I also believe they can make the language difficult to learn and use. => ... => Application-area-specific sets of class hierarchies => aiming at encapsulations of rather large concepts relevant to the => application area are probably a better way to build meaningful, => reusable classes than the Single Monolithic Hierarchy (like Smalltalk => and the NIH classes) and are certainly better than building a house => from grains of sand (like building "stack" and "linked list" and "hash => table" classes and then applications atop them -- yech). A few reactions: first, the idea of creating application-specific classes related to the relative concepts of the application. I think this is the best advice possible and is not emphasised enough. If the application's major components correspond cleanly to the major concepts then it will be easier to understand, modify, reuse, and extend, no matter how those classes are implemented. I agree that the "Single Monolithic Hierarchy" (SMH) is not the way to go at this time. Not because an SMH is a bad idea, but because C++ is not being designed to have one. I also agree that "building a house from grains of sand" is an empty strategy in and of itself. Stacks, linked lists, and hash tables, etc. are nice things to have. As are numbers, strings, and booleans. But in these days of object-oriented programming they are the least interesting things to have. It may be that a lot of programmers learn C++ and then proceed to use it to build their data structures and then plug them in to their C-like (or perhaps Modula/Ada-like) programs. There are some useful class hierarchies, though, somewhere between the SMH and a flat collection of data structures. For example, when some algorithm only needs the most general concepts of a collection, it should not have to know whether any particular collection is implemented as a hash table, linked list, array, or whatever. => >Of these, 1 through 5 will eventually go away. 6 never will. => => Ridiculous. => ... => The concept of "class" is so intuitively appealing that it improves => program design immediately. I don't think it's so ridiculous. I think C++ is complicated, not designing classes conceptually. Time will tell, everyone will have their own experiences. => Neither is the Smalltalk class hierarchy or its environment trivial. Triviality is not expected, although it's always welcome. The difference is the Smalltalk language lends to understanding where many aspects of C++ detract from understanding... in my *opinion*! And, yes, all of you flamers with your pilot lights ready, I know that in many ways C++ is more efficient than Smalltalk. I know there are advantages to both. Only send bits my way if you really need to. => > Dr. Thomas Keffer | Internet: keffer@sperm.ocean.washington.edu => Dr. James M. Coggins coggins@cs.unc.edu -- Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan Mentor Graphics Corporation | plogan@pdx.MENTOR.COM Beaverton, Oregon | (Remember I represent my self, not Mentor.)