From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,be30d7bb9651853b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-12-17 22:39:41 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!newsserver.jvnc.net!netnews.upenn.edu!dsinc!ub!news.kei.com!bloom-beacon.mit.edu!news.bu.edu!inmet!dsd!stt From: stt@dsd.camb.inmet.com (Tucker Taft) Subject: Re: Ada 90 inheritance request? Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. References: <3ca3vl$n14@lang8.cs.nyu.edu> Date: Sat, 17 Dec 1994 13:55:36 GMT Date: 1994-12-17T13:55:36+00:00 List-Id: In article , John Goodsen wrote: >I am dismayed at how anyone could look at this so-called "solution" to >multiple inheritance and walk away comfortable that Ada9X properly >supports MI. The lack of *direct* support for MI in Ada 9X, is IMHO, >a serious foobar that has to this point been explained away by the >ivory tower language designers ... Feel free to accuse of us of all kinds of crimes against nature, but please don't put us in an ivory tower ;-). I trust that those who know me recognize that I tend to live more in the cement dungeon of language design, scrabbling around in the cement dust of human engineering, implementation concerns, efficiency, etc. The Ada 9X mapping/revision team consisted almost entirely of dedicated, very experienced, Ada and other-language programmers with a strong penchant for designing the most productive, reliable, readable, and usable language they knew how, given the constraints of the process. An easy to use, intuitive, efficient, straightforward, multiple inheritance mechanism in Ada 9X would have been great. Unfortunately, we have never seen such a beast. Perhaps you have. What we found when investigating ways to support multiple inheritance was that everybody knew what was the best way to do it -- their own way! When we have encountered such things in the past during language design, the conclusion to be drawn is that implementing multiple inheritance is still a *programming* problem, not a language design problem. If even two existing OOP languages did Multiple Inheritance the same way we would have seen that as a reasonable starting place. But the fact is that the rules for dealing with the inevitable additional complexities of multiple inheritance are different in essentially every langauge we looked at. Even Sather and Eiffel, which otherwise have a lot in common, differ in how they resolve the MI issues. C++ in its usual pragmatic way provides two different ways to do MI, using regular or virtual base classes. CLOS just merges based on names and a search order for methods. Eiffel provides renaming. Etc... By constrast, all of the languages agree on how to do single inheritance in the language, and it is essentially unchanged since the days of Simula '67. It is intuitive, efficient, straightforward, reliable, type-safe, productive, useful, ... That sounds like a feature for Ada ;-). Note that Smalltalk, Object Pascal, Modula-3, Oberon-X, and Objective-C all have chosen to stick with single inheritance. There are (ivory tower ;-) researchers studying ways to add MI in some of these languages, but the practitioners seem to be plowing ahead very productively and happily relying on the rock-solid single inheritance, building up their conceptual multiple inheritance hierarchies as they see fit, in an application-specific way. We expect that most Ada 95 programmers will find the same thing. Single inheritance is there, in its full glory and simplicity, right in the language. In addition, there are building blocks for constructing robust application-specific solutions to problems that might otherwise use a language-provided multiple inheritance mechanism. Furthermore, what happens in some cases, is that the language-provided multiple inheritance mechanism turns out to be not quite the right solution for a given problem that is "reminiscent" of multiple inheritance. Then you have the worst of both worlds -- a language made more complex by the addition of linguistic multiple inheritance, and an application made more difficult by the lack of appropriate building blocks for solving the problem the "right" way. To summarize, it is our view that it is a bit ivory-towerish to look at a language, and say that if it doesn't have feature X implemented in some specific way, then it is useless and FUBAR. I can't tell you how many times we have been threatened over the past 5 years with similar statements about all kinds of obscure features. It is interesting to follow the C++ standardization process, where the same desparate statements are made in support of one obscure feature after another. The fact is that a good language has its own self-consistent logic, and some features make a good addition to that structure, and others just don't fit. We couldn't find a language-provided multiple inheritance mechanism that enhanced Ada. We could find plenty that made it more complicated, less intuitive, less reliable, less readable, etc. We welcomed proposals and suggestions for one that would be a net addition to the language, but on deeper investigation into the nitty-gritty, we never found one where the pluses outweighed the minuses. We had an "ivory-tower" desire to try to find one, but we had a more practical concern that we didn't want to FU the language to get one in, just for the marketing potential. We wanted the features to be useful and reliable, not just there for show. Perhaps the designers of Ada 007 will find the silver bullet... Meanwhile, we will be productively building reliable systems in our cement basement. >John Goodsen Currently on-site at: >The Dalmatian Group JP Morgan >User Interface Specialists 60 Wall St., New York City >jgoodsen@radsoft.com jgoodsen@jpmorgan.com S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138