* Does Ada really need MULTIPLE inheritance? @ 1989-10-16 13:57 "Norman H. Cohen" 1989-10-17 17:23 ` David A Eichmann,316K 1989-10-19 2:27 ` William Thomas Wolfe, 2847 0 siblings, 2 replies; 14+ messages in thread From: "Norman H. Cohen" @ 1989-10-16 13:57 UTC (permalink / raw) Two recent workshops focused on adding support for object-oriented programming to Ada. One, sponsored by MITRE Corporation, was held September 11-13 at Woburn, Massachusetts. The Workshop on Language Issues for Reuse: Ada for the 90's, sponsored by University of Maine was held at Deer Isle, Maine, September 25-29. Specific proposals for supporting object-oriented programming in Ada were discussed at each workshop. I'll leave discussion of the details to the final workshop reports, which are now in preparation, but I do want to mention two areas of consensus reached at both workshops: (1) Ada should support inheritance. (2) There is no convincing need for MULTIPLE inheritance. Since nobody at either workshop was a strenuous advocate of multiple inheritance, I would like to see the argument for multiple inheritance presented here. Among the thoughts that contributed to the consensus AGAINST multiple inheritance were: (1) In many cases, the effect of multiple inheritance could be achieved also by instantiating a generic unit defining a subclass of a class given by a generic parameter. This allows different classes to be extended in a uniform way. (2) Multiple inheritance may seem essential in some object-oriented languages because inheritance is the only importation mechanism. Ada can get by with a WITH clause in many contexts where other languages use multiple inheritance. In Eiffel, for example, one inherits from class MATH, which has operations but no state data, to achieve the effect of WITHing a math package in Ada. (3) In some language proposals, multiple inheritance is a natural generalization of single inheritance. In other proposals, however, multiple inheritance is difficult to accommodate. For example, the view that subclasses should be treated as Ada subtypes has much going for it (for details, see my proposal "Ada Subtypes as Subclasses," Research Report RC14912, which can be obtained by writing to IBM Thomas J. Watson Research Center, Distribution Services F-11 Stormytown, P.O. Box 218, Yorktown Heights, NY 10598), but it is incompatible with multiple inheritance in a strongly typed language like Ada. (4) Many (including Bertrand Meyer) hold that the inheritance hierarchy should reflect an "is-a" relationship. That is, each instance of a subclass should be an instance of its immediate superclass(es) as well. There are a few well-known examples where the "is-a" relationship holds with multiple parents (a text window is both a text file and a window, e.g.) but such examples are rare, too rare to justify further complication of the language. (5) Multiple inheritance makes it difficult to determine the source of a subclass's features, or to determine the impact of changing the interface of a superclass. It tends to lead to undisciplined software composition that may be fine for exploratory programming but is unacceptable for the huge projects in which Ada is used, projects that require strict configuration management. Norman Cohen ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does Ada really need MULTIPLE inheritance? 1989-10-16 13:57 Does Ada really need MULTIPLE inheritance? "Norman H. Cohen" @ 1989-10-17 17:23 ` David A Eichmann,316K 1989-10-17 20:49 ` David Chase 1989-10-30 17:12 ` Does Ada really need MULTIPLE inheritance? Paul Baker 1989-10-19 2:27 ` William Thomas Wolfe, 2847 1 sibling, 2 replies; 14+ messages in thread From: David A Eichmann,316K @ 1989-10-17 17:23 UTC (permalink / raw) From article <8910161521.AA27039@ajpo.sei.cmu.edu>, by NCOHEN@IBM.COM ("Norman H. Cohen"): ... > Since nobody at either workshop was a strenuous advocate of multiple > inheritance, I would like to see the argument for multiple inheritance OK, let's say I'm creating refinements of a general concept of vehicle, which contains two attributes, means of propulsion(motor, air, etc.) and operating medium(land, air, water). I can make an initial refinement of air vehicles (adding appropriate attributes), land vehicles, and water vehicles - refining by medium; or I can refine to motor vehicles, air (powered) vehicles, etc - refining by propulsion. With single inheritance, I must choose one over the other. With multiple inheritance, there is no need. A motorized air vehicle is an instance of both air vehicle AND an instance of motorized vehicle. My initial design choice is not coloring subsequent interpretations and perspectives on the objects in question. ----- David Eichmann Dept. of Statistics and Computer Science West Virginia University Phone: (304) 293-3607 Morgantown, WV 26506 Email: eichmann@a.cs.wvu.wvnet.edu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does Ada really need MULTIPLE inheritance? 1989-10-17 17:23 ` David A Eichmann,316K @ 1989-10-17 20:49 ` David Chase 1989-10-21 19:39 ` Inheritance & limited private types William Thomas Wolfe, 2847 1989-10-30 17:12 ` Does Ada really need MULTIPLE inheritance? Paul Baker 1 sibling, 1 reply; 14+ messages in thread From: David Chase @ 1989-10-17 20:49 UTC (permalink / raw) I'm not well-versed in Ada, but people I've talked to ensure me that Ada has something similar to the "opaque types" of Modula-2 and Modula-3. Combining opaque types and multiple inheritance can lead to some nasty problems. I don't have a solution; just a problem. I'm assuming that by "multiple inheritance", the people discussing it means the ability to (1) extend an existing type or (2) refine an abstract (virtual, in the C++ lingo) type. In the first case one might specialize "vehicle" into "car" and "truck"; in the second case, one might provide a method for "compare" for an abstract "Comparable", and take advantage of all the code already written to deal with Comparable objects. It's the second case, and overriding of existing message-method bindings in general, that causes the problem. Suppose I have a type T1, and it has a binding message-method binding M1-m1a (M1 is the message, m1a is the method for it). Supposing I have a type T2 which inherits from T1, and uses the M1-m1a binding. T1 = OBJECT METHODS M1() := m1a END; T2 = T1 OBJECT METHODS ... END; Now suppose I export T2 opaquely, along with a procedure P2 which does something useful with a T2. OPAQUE OBJECT T2; (* I'm making up syntax as I go along *) PROCEDURE P2(x:T2) ...; Now suppose I have a type T3 which inherits from T2, and also inherits from T1, but uses the message-method binding M1-m1b. I claim that (1) this should be legal, because the programmer has no way of knowing that it should be illegal (information hiding, right?) (2) An object O of type T3 should have the binding M1-m1b where it is visible that O is a T3 (because that's what the programmer said) (3) An object O of type T3 should have the binding M1-m1a whenever it is in a context where it is known to be a T2, but not known to be a T3 (because the programmer should not be able to invalidate the correctness of a module if the internals of the module are hidden). That is (elaborating (3)) if P2 is called, then within P2 the binding should be M1-m1a, and if O.M1 is sent in that context, then within the code for m1a the binding should still be M1-m1a. That is, a second time, changes to the method bindings for T1 by a subtype T3 *must not* change the behavior of T3 when considered as a T2; any proofs about the behavior of a T2 would thus go out the window (and the programmer would be clueless, because the dependence of T2 on T1's message-method bindings is hidden). T3 = T1, T2 OBJECT METHODS M1 := m2b END; at some point in the program, VAR x : T3; ... P2(x); (* x MUST act as a T2 in P2, including the binding of M1 to m1a. *) ... x.M1() (* This MUST call method m1b, not m1a. *) I am *not* arguing that this should be the case if T2 is not opaque; in that case everything is in the clear, and either an error message or a change in T2's behavior is allowed. This nasty situation could be avoided by creative prohibition (objects cannot be opaquely exported -- yuck; opaque types cannot be inherited -- yuck; no multiple inheritance -- many people say yuck, but that's what we live with in Modula-3), but I'd be even happier if I could figure it out. David ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inheritance & limited private types 1989-10-17 20:49 ` David Chase @ 1989-10-21 19:39 ` William Thomas Wolfe, 2847 1989-10-22 7:00 ` Vinod Grover 0 siblings, 1 reply; 14+ messages in thread From: William Thomas Wolfe, 2847 @ 1989-10-21 19:39 UTC (permalink / raw) [For those people in newsgroups other than comp.lang.ada who are also seeing this article: this thread arose in the context of a discussion in comp.lang.ada regarding the addition of multiple inheritance to Ada as part of the current Ada 9X revision process.] From chase@Ozona.orc.olivetti.com (David Chase): > I'm not well-versed in Ada, but people I've talked to ensure me that > Ada has something similar to the "opaque types" of Modula-2 and > Modula-3. Combining opaque types and multiple inheritance can lead > to some nasty problems. I don't have a solution; just a problem. OK, first I'll rephrase the problem in a way that Ada people will find easier to follow. David assumes that there are two uses for inheritance; the first is specialization, in which one would take the abstraction "vehicle" and provide additional operations in order to define abstractions such as "car" or "truck". The second is derivation, in which one would take an existing abstraction and shape it into a new abstraction, using the implementations provided by the old abstraction as appropriate and overriding operations with new implementations as necessary. > It's the second case, and overriding of existing message-method > bindings in general, that causes the problem. The overriding of the current implementation for only certain operations of a type does cause problems in that in general, a good implementation for a given data abstraction will take maximum advantage of the relationships between the various operations, thus creating an implementation in which the data structures and algorithms involved depend strongly on the fact that exactly that set of operations is to be supported. For example, a standard queue abstraction might be implemented by a singly-linked list structure in conjunction with a descriptor which points to the first and last elements in the list, in order to efficiently support only the operations Enqueue and Dequeue. But now suppose that we wish to support a priority queue instead, and we wanted to override the existing Dequeue operation with a new one. The new operation would scan the entire list in order to find the element having the highest priority, and then dequeue that element. Unfortunately, this is an O (n) algorithm, which is quite inefficient relative to the O (log n) algorithms which could be used if the new abstraction was supported by a binomial forest rather than a linked list. This represents the result of a tradeoff. By using inheritance in conjunction with the implementation of the old abstraction, we have traded off implementation quality in exchange for speed of implementation. The priority queue implementation obtained via the overriding of inherited operations is of very low quality, but this may or may not be an important consideration relative to the cost of providing a high-quality implementation. It has long been recognized that the time to worry about product efficiency is AFTER the product has been developed and put through a profiler to determine where the bottlenecks are in the system, since in this way the high cost of maximizing efficiency can be directed to the points at which it will do the most good. This principle extends to our derived priority queue implementation; if the profiler indicates that a software system is running with unacceptably slow speed due primarily to the time required to do priority queue operations, then a more sophisticated implementation of the priority queue which takes maximum advantage of the relationships between the set of required operations is probably a good idea. We then apply economic principles once again and try to find a software components supplier which will sell us a high-performance priority queue implementation, complete with formal specifications for each operation and timing results for typical workloads. In general, the components supplier will even be able to offer a number of different implementations, some of which will emphasize the particular operations which are most crucial to your system at the expense of others which are not as important. Now back to the problem under consideration... :-) > Suppose I have a type T1, and it has a message-method binding [...] Rephrasing, here is the problem: package Example is -- this is the specification type T2 is limited private; -- can't know or use the details procedure DO_SOMETHING_WITH (Parameter : in out T2); end Example; package body Example is -- this is the implementation -- type T1 has the operation OP1, and implementation IMP1. -- type T2 inherits operation OP1 and implementation IMP1 from T1. end Example; -- Now the user of package Example declares a new type, T3, -- which is_a T1 and also is_a T2. The user then specifies -- a new implementation, IMP2, for OP1. > I claim that (1) this should be legal, because the programmer has > no way of knowing that it should be illegal (information hiding, > right?) (2) An object O of type T3 should have the binding [OP1-IMP2] > where it is visible that O is a T3 (because that's what the programmer > said) (3) An object O of type T3 should have the binding [OP1-IMP1] > whenever it is in a context where it is known to be a T2, but not > known to be a T3 (because the programmer should not be able to > invalidate the correctness of a module if the internals of the > module are hidden). [In other words, if procedure DO_SOMETHING_WITH > is called, which expects a parameter of type T2, then IMP1 should be > used for the object of type T3 because it is expected to perform as > a T2 in that context.] [... C]hanges to the [implementation] bindings > for T1 by a subtype T3 *must not* change the behavior of T3 when > considered as a T2; any proofs about the behavior of a T2 would > thus go out the window (and the programmer would be clueless, because > the dependence of T2 on T1's [specification-implementation] bindings > is hidden). [...] > > I am *not* arguing that this should be the case if T2 is not opaque; > in that case everything is in the clear, and either an error message > or a change in T2's behavior is allowed. This nasty situation could > be avoided by creative prohibition (objects cannot be opaquely > exported -- yuck; opaque types cannot be inherited -- yuck; no > multiple inheritance -- many people say yuck, but that's what we live > with in Modula-3), but I'd be even happier if I could figure it out. First, let me give a reference to an important tutorial regarding the "synthesis of typing systems", as found in "Ada, an advanced language incorporating extensive support for various forms of abstraction", with "the powerful and flexible capabilities of OOP [object-oriented-programming]", which is entitled "Type Theories and Object-Oriented Programming" and can be found in ACM Computing Surveys, Vol. 20, No. 1, March 1988. Actual progress toward this objective is described by Wilf R. LaLonde in "Designing Families of Data Types Using Exemplars" (ACM Transactions on Programming Languages and Systems, Vol. 11, No. 2, April 1989), who argues that "designing families of data types is a programming-in-the- large problem", that "class-based systems need the notion of private types if they are to surmount their current limitations", and that "an advanced system should support the programming maxim that designers can switch implementations as they choose without impacting users. We show, using the implementation technique that we call programming by exemplars, that conventional class-based systems cannot help but violate the maxim. Exemplar-based systems support it easily.". Finally, I agree with each of your claims (1), (2), and (3), and in my opinion they are a natural consequence of the information hiding concept. As far as T3 is concerned, T2 does not HAVE any operations other than procedure DO_SOMETHING_WITH. Therefore, there can be no conflict between T3's inheritance of OP1 from T1, T3's provision of IMP2 for OP1, and T3's status as a T2 having the single operation DO_SOMETHING_WITH. The fact that T2 was declared internally to be an object having the operation OP1 as inherited from T1 is hidden from T3, and therefore is only of consequence within the package body which provides an implementation of T2 and its associated operation. Within that operation, we know that the parameter is of type T2, and therefore this "view" of T3 as a T2 will be supported. The T2 capabilities are visible to procedures such as DO_SOMETHING_WITH which have the needed authorization to view T2s, while also being hidden from T3 and from anything else which is external to the T2 implementation. Bill Wolfe, wtwolfe@hubcap.clemson.edu P.S. I will be in Pittsburgh during the week of October 23-27 for the Tri-Ada '89 conference, and therefore will not be able to respond to any followups until at least October 30th. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inheritance & limited private types 1989-10-21 19:39 ` Inheritance & limited private types William Thomas Wolfe, 2847 @ 1989-10-22 7:00 ` Vinod Grover 1989-10-22 18:03 ` Inheritance & limited private t stt ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Vinod Grover @ 1989-10-22 7:00 UTC (permalink / raw) In article <6845@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > It has long been recognized that the time to worry about product > efficiency is AFTER the product has been developed and put through > a profiler to determine where the bottlenecks are in the system, > since in this way the high cost of maximizing efficiency can be > directed to the points at which it will do the most good. For those of us without profilers, I suppose, there is no hope. Or perhaps we should worry about efficiency before the product has been developed, or perhaps not to worry about efficiency at all. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inheritance & limited private t 1989-10-22 7:00 ` Vinod Grover @ 1989-10-22 18:03 ` stt 1989-10-22 20:22 ` Inheritance & limited private types Barry Margolin 1989-10-27 0:04 ` Inheritance & limited private types Dick Karpinski 2 siblings, 0 replies; 14+ messages in thread From: stt @ 1989-10-22 18:03 UTC (permalink / raw) "It has long been recognized..." by whom? If there is any lesson I have learned myself over the years is that if you don't worry about efficiency from the beginning, you will never achieve aggressive performance goals. -Tucker Taft Intermetrics, Inc. Cambridge, MA 02138 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inheritance & limited private types 1989-10-22 7:00 ` Vinod Grover 1989-10-22 18:03 ` Inheritance & limited private t stt @ 1989-10-22 20:22 ` Barry Margolin 1989-10-23 0:39 ` Ted Dunning 1989-10-27 15:44 ` Paul Pedersen 1989-10-27 0:04 ` Inheritance & limited private types Dick Karpinski 2 siblings, 2 replies; 14+ messages in thread From: Barry Margolin @ 1989-10-22 20:22 UTC (permalink / raw) In article <126675@sun.Eng.Sun.COM> grover@sun.UUCP (Vinod Grover) writes: >For those of us without profilers, I suppose, there is no hope. Or perhaps >we should worry about efficiency before the product has been developed, or >perhaps not to worry about efficiency at all. Making a program efficient without a profiler is like making a program work without a debugger. Sure, you can manually sprinkle your code with print statements and timing statements, but it's not an efficient way to do it. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inheritance & limited private types 1989-10-22 20:22 ` Inheritance & limited private types Barry Margolin @ 1989-10-23 0:39 ` Ted Dunning 1989-10-27 15:44 ` Paul Pedersen 1 sibling, 0 replies; 14+ messages in thread From: Ted Dunning @ 1989-10-23 0:39 UTC (permalink / raw) In article <31018@news.Think.COM> barmar@kulla (Barry Margolin) writes: In article <126675@sun.Eng.Sun.COM> grover@sun.UUCP (Vinod Grover) writes: ^^^^^^^^^^^^^^^ >For those of us without profilers, I suppose, there is no hope. Or perhaps >we should worry about efficiency before the product has been developed, or >perhaps not to worry about efficiency at all. Making a program efficient without a profiler is like making a program work without a debugger. Sure, you can manually sprinkle your code with print statements and timing statements, but it's not an efficient way to do it. no kidding. but how is it that this guy from sun doesn't think that he has any profilers? -- ted@nmsu.edu Dem Dichter war so wohl daheime In Schildas teurem Eichenhain! Dort wob ich meine zarten Reime Aus Veilchenduft und Mondenschein ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inheritance & limited private types 1989-10-22 20:22 ` Inheritance & limited private types Barry Margolin 1989-10-23 0:39 ` Ted Dunning @ 1989-10-27 15:44 ` Paul Pedersen 1989-10-27 17:50 ` Robert Firth 1 sibling, 1 reply; 14+ messages in thread From: Paul Pedersen @ 1989-10-27 15:44 UTC (permalink / raw) In article <31018@news.Think.COM> barmar@kulla (Barry Margolin) writes: > >Making a program efficient without a profiler is like making a program work >without a debugger. Sure, you can manually sprinkle your code with print >statements and timing statements, but it's not an efficient way to do it. > I spent some time last year trying to profile a large UNIX-based system running on a 386. Turned out to be a waste of time since profiling is driven by UNIX clock-ticks which, at least on our system, is 100t/sec. I found that the software (under test) could execute up to 30 function calls between ticks, so most functions never got hit by the interupt, and all time-spent-in-function's were meaningless. Speeding up the interrupt frequency is apparently not a good idea since most time will then be spent in context-switch's. The conclusion I came to was that it is not possible to do profiling using UNIX on a fast processor, short of using a logic analyzer and a lot of interpreting software (far from sure that this is even feasable). I would be *very* interested in hearing from anybody who has solved this problem (I gave up) :-) Paul Pedersen (pedersen@philmtl) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inheritance & limited private types 1989-10-27 15:44 ` Paul Pedersen @ 1989-10-27 17:50 ` Robert Firth 1989-10-27 22:32 ` Profiling (was Re: Inheritance & limited private types) Barry Margolin 0 siblings, 1 reply; 14+ messages in thread From: Robert Firth @ 1989-10-27 17:50 UTC (permalink / raw) In article <800@philmtl.philips.ca> pedersen@philmtl.philips.ca (Paul Pedersen) writes: >The conclusion I came to was that it is not possible to do profiling >using UNIX on a fast processor, short of using a logic analyzer and a >lot of interpreting software (far from sure that this is even feasable). > >I would be *very* interested in hearing from anybody who has solved this >problem (I gave up) :-) Gee, I implemented profiling on this Unix machine in an afternoon. Admittedly, I was helped by the existence of a system call 'profil', which does all the real work. The purpose of profiling is to find out where the program is spending a lot of its time. Now, the profiling command samples the program counter 100 times a second, so in a one-minute run that is 6000 samples. Any subprogram body that consumes more than 1% of the mill will therefore generate on average more than 60 hits, which is surely a meaningful number. If no program run ever takes more than a minute, few Unix users will care about having it tuned. And if a given function uses less than 1% of the mill, you don't care about tuning it. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Profiling (was Re: Inheritance & limited private types) 1989-10-27 17:50 ` Robert Firth @ 1989-10-27 22:32 ` Barry Margolin 0 siblings, 0 replies; 14+ messages in thread From: Barry Margolin @ 1989-10-27 22:32 UTC (permalink / raw) [Note that I've directed followups to comp.lang.misc, as this no longer seems to be about Ada.] In article <4697@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >In article <800@philmtl.philips.ca> pedersen@philmtl.philips.ca (Paul Pedersen) writes: >>The conclusion I came to was that it is not possible to do profiling >>using UNIX on a fast processor, short of using a logic analyzer and a >>lot of interpreting software (far from sure that this is even feasable). >>I would be *very* interested in hearing from anybody who has solved this >>problem (I gave up) :-) >Gee, I implemented profiling on this Unix machine in an afternoon. >Admittedly, I was helped by the existence of a system call 'profil', >which does all the real work. > >The purpose of profiling is to find out where the program is spending >a lot of its time. Now, the profiling command samples the program >counter 100 times a second, so in a one-minute run that is 6000 >samples. Any subprogram body that consumes more than 1% of the mill >will therefore generate on average more than 60 hits, which is surely >a meaningful number. This is called "statistical program counter metering" on the system I use (Symbolics Lisp Machines); until last year it was the only metering facility provided by Symbolics. They implemented it using microcode microtasks (Symbolics 36xx machines can run up to 5 concurrent microtasks) rather than interrupts, so the overhead is virtually nil and it samples very frequently. To be most useful, statistical PC metering should permit you to specify the frequency, particularly if your application contains loops (how many significant applications don't?). This is because the period of the loop might be close to the period of the PC sampling, and you would get distorted data. A way to get more precise metering is to make use of a trap-on-call/return facility. This can be implemented in hardware (as on the Lispm) or in software (the subroutine calling sequence could check a flag), or in the compiler (an option to the compiler tells it to generate metering code). Whenever a function call is made the trap handler records the time, and when it returns the elapsed time can be recorded. To get more precise timings, of course, you need a more precise clock; what you need is an independent high-frequency clock chip that can be read, rather than a clock that simply interrupts the processor every Nth of a second. Symbolics machines have a 60th-of-a-second interrupting clock to drive the scheduler and time-of-day clock, and a separate microsecond clock that can be read on demand (there's also a third clock, called the calendar clock, running in the front end processor, for use when Lisp is shut down). Another way of metering is to just count the number of times particular functions are called. This can be done using the same mechanisms as the above, but it doesn't require the high-frequency clock. Instead of reading the clock, the trap handler just increments a counter for the function being called. This is often useful for determining where the likely hot spots will be. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inheritance & limited private types 1989-10-22 7:00 ` Vinod Grover 1989-10-22 18:03 ` Inheritance & limited private t stt 1989-10-22 20:22 ` Inheritance & limited private types Barry Margolin @ 1989-10-27 0:04 ` Dick Karpinski 2 siblings, 0 replies; 14+ messages in thread From: Dick Karpinski @ 1989-10-27 0:04 UTC (permalink / raw) In article <126675@sun.Eng.Sun.COM> grover@sun.UUCP (Vinod Grover) writes: >In article <6845@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >> It has long been recognized that the time to worry about product >> efficiency is AFTER the product has been developed and put through >> a profiler to determine where the bottlenecks are in the system, >> since in this way the high cost of maximizing efficiency can be >> directed to the points at which it will do the most good. > >For those of us without profilers, I suppose, there is no hope. Or perhaps >we should worry about efficiency before the product has been developed, or >perhaps not to worry about efficiency at all. It seems obvious to me that such of us that have that problem should fix it by making a profiler. Failing sufficient interest to do that job well, I have a simple technique for making inserted timing probes do the necessary work. My approach installs numbered probes into the application to collect timing information from the system and build a RAM table which is dumped in human readable form at end of run. In extreme cases (such as no clock) human keystrokes can be used to fake the clock. Remember, we only need crude information to detect which components are using most of the time. I'll happily tutor folks who need to do this by phone or email. Dick Dick Karpinski Manager of Minicomputer Services, UCSF Computer Center Domain: dick@cca.ucsf.edu (415) 476-4529 (11-7) BITNET: dick@ucsfcca or dick@ucsfvm (415) 658-6803 (Home) USPS: U-76 UCSF, San Francisco, CA 94143-0704 (415) 658-3797 (ans) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does Ada really need MULTIPLE inheritance? 1989-10-17 17:23 ` David A Eichmann,316K 1989-10-17 20:49 ` David Chase @ 1989-10-30 17:12 ` Paul Baker 1 sibling, 0 replies; 14+ messages in thread From: Paul Baker @ 1989-10-30 17:12 UTC (permalink / raw) >From article <8910161521.AA27039@ajpo.sei.cmu.edu>, > by NCOHEN@IBM.COM ("Norman H. Cohen"): > Since nobody at either workshop was a strenuous advocate of multiple > inheritance, I would like to see the argument for multiple inheritance I attended one of these workshops and didn't advocate multiple inheritance. The response to Norm's remark on this network seems to be based on the notion that the power of multiple inheritance was overlooked at these workshops. If my memory serves, the issue on the table was the value of this feature in the context of its dangers and the fact that it is not essential for OOP. Its power was recognized. The danger is that there is currently no rigorous notion of how we shall interpret the fusion of methods from alternative lineages. CLOS offers a fixed and reasonable interpretation of the order of delegation but the order is not based on any convincing metaphor. In the face of this problem, it will be difficult to teach design for multiple inheritance and hard for one developer to maintain another's system. Multiple inheritance is not essential because its effects can be achieved by defining a new class whose slots include components from various classes. The developer must then define all the new methods - none are inherited automatically. Naturally, that new definition can be a delegation to one of the ancestor classes. Thus, composition achieves the same functional effect as inheritance but requires an explicit explanation of the intended fusion of methods. ---------- Paul L. Baker CTA INCORPORATED E-MAIL: bakerp@ajpo.sei.cmu.edu PHONE: 301-816-1242 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does Ada really need MULTIPLE inheritance? 1989-10-16 13:57 Does Ada really need MULTIPLE inheritance? "Norman H. Cohen" 1989-10-17 17:23 ` David A Eichmann,316K @ 1989-10-19 2:27 ` William Thomas Wolfe, 2847 1 sibling, 0 replies; 14+ messages in thread From: William Thomas Wolfe, 2847 @ 1989-10-19 2:27 UTC (permalink / raw) From NCOHEN@IBM.COM (Norman H. Cohen): > Two recent workshops focused on adding support for object-oriented > programming to Ada. [...] I do want to mention two areas of consensus > reached at both workshops: > (1) Ada should support inheritance. > (2) There is no convincing need for MULTIPLE inheritance. > Since nobody at either workshop was a strenuous advocate of multiple > inheritance, I would like to see the argument for multiple inheritance > presented here. David Eichmann has presented one; a few more appear below. > Among the thoughts that contributed to the consensus > AGAINST multiple inheritance were: > > (1) In many cases, the effect of multiple inheritance could be > achieved also by instantiating a generic unit defining a subclass > of a class given by a generic parameter. This allows different > classes to be extended in a uniform way. > > (2) Multiple inheritance may seem essential in some object-oriented > languages because inheritance is the only importation mechanism. > Ada can get by with a WITH clause in many contexts where other > languages use multiple inheritance. In Eiffel, for example, one > inherits from class MATH, which has operations but no state data, > to achieve the effect of WITHing a math package in Ada. I would submit that the generic mechanism and the multiple inheritance mechanism are conceptually orthogonal; trying to use generics to simulate multiple inheritance is like trying to simulate recursion with a stack, etc.; although it may be possible, its desirability in terms of program clarity is highly questionable. > (3) In some language proposals, multiple inheritance is a natural > generalization of single inheritance. In other proposals, > however, multiple inheritance is difficult to accommodate. > For example, the view that subclasses should be treated as Ada > subtypes has much going for it (for details, see my proposal > "Ada Subtypes as Subclasses," Research Report RC14912, which can > be obtained by writing to IBM Thomas J. Watson Research Center, > Distribution Services F-11 Stormytown, P.O. Box 218, Yorktown > Heights, NY 10598), but it is incompatible with multiple > inheritance in a strongly typed language like Ada. Subclassing and subtyping are two somewhat similar, but distinct concepts; both need to be properly supported. I see no reason why this could not be accomplished. > (4) Many (including Bertrand Meyer) hold that the inheritance > hierarchy should reflect an "is-a" relationship. That is, each > instance of a subclass should be an instance of its immediate > superclass(es) as well. There are a few well-known examples > where the "is-a" relationship holds with multiple parents (a text > window is both a text file and a window, e.g.) but such examples > are rare, too rare to justify further complication of the > language. I would argue first that such examples are not necessarily rare; it may simply be that the lack of an ability to express the idea at all has greatly restricted the amount of time spent considering the possibilities, and that many valid applications of the concept will emerge once its expression becomes possible. > (5) Multiple inheritance makes it difficult to determine the source > of a subclass's features, or to determine the impact of changing > the interface of a superclass. It tends to lead to undisciplined > software composition that may be fine for exploratory programming > but is unacceptable for the huge projects in which Ada is used, > projects that require strict configuration management. Determining the source of a subclass's operations can be done with an appropriate tool automatically. Determining the impact of changing the interface of a superclass is similar to the problem of determining the impact of a change to a package interface; when the syntactic interface to a package changes, there is a "direct" impact in that certain portions of code (the code withing the modified spec) must be recompiled. However, this does not bound the *semantic* impact; semantic modifications can be made without even causing recompilation, and can propagate throughout the system essentially unchecked. Consider what would happen if something as heavily relied upon as a mathematics package were to be semantically modified; newly linked programs everywhere could begin to fail through absolutely no fault of their own, whether because of subprograms that failed catastrophically as a direct result of the modification or because of subprograms that began to deliver subtly incorrect results. The only answer to this, I think, would be to incorporate something like Anna/TSL into the definition of Ada, and even then the costs of specifying and enforcing semantics so tightly would be considerable. In short, there's no easy answer, and no escape from the problem. Finally, the point about it tending to lead to undisciplined software composition is certainly not without supporting evidence, in that the capability has so far been most extensively used in support of exploratory programming. But it is not my purpose to enable exploratory programming to be done; my objective is to enable the natural expression of real-world relationships, and also to enable the systematic reuse of concepts which have already been expressed. Perhaps ideas will emerge which will lead to a means of restricting undisciplined use of multiple inheritance, just as ideas such as doing type-checking and making any arithmetic difficult have successfully restricted the undisciplined use of pointers. Bill Wolfe, wtwolfe@hubcap.clemson.edu ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~1989-10-30 17:12 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1989-10-16 13:57 Does Ada really need MULTIPLE inheritance? "Norman H. Cohen" 1989-10-17 17:23 ` David A Eichmann,316K 1989-10-17 20:49 ` David Chase 1989-10-21 19:39 ` Inheritance & limited private types William Thomas Wolfe, 2847 1989-10-22 7:00 ` Vinod Grover 1989-10-22 18:03 ` Inheritance & limited private t stt 1989-10-22 20:22 ` Inheritance & limited private types Barry Margolin 1989-10-23 0:39 ` Ted Dunning 1989-10-27 15:44 ` Paul Pedersen 1989-10-27 17:50 ` Robert Firth 1989-10-27 22:32 ` Profiling (was Re: Inheritance & limited private types) Barry Margolin 1989-10-27 0:04 ` Inheritance & limited private types Dick Karpinski 1989-10-30 17:12 ` Does Ada really need MULTIPLE inheritance? Paul Baker 1989-10-19 2:27 ` William Thomas Wolfe, 2847
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox