kempf@hplabsz.HPL.HP.COM (Jim Kempf) (09/29/87)
In article <1096@g.gp.cs.cmu.edu>, dld@g.gp.cs.cmu.edu (David Detlefs) writes: > > How do inheritance and parameterized classes interact? I think that I would be very careful indeed about introducing both multiple inheritance and parameterized types into a language without careful thought about how the two interact. C++ is already a fairly rich language, and addition of other constructs may push it over the brink. Those who complain about excessive featurism in Ada and see C++ as relief should be concerned. I am even a little uneasy about introducting multiple inheritance into a language like C++ which depends on traditional linker/library technology for software reuse. The semantics of multiple inheritance are difficult even in a language like Common Lisp, where a more flexible linking discipline gives the language developer more control, and a richer runtime environment allows more information about libraries to be made available. The issue is not just one of implementation, but also whether the semantics match well with the programmer's model of how to do things, and whether the programming environment can support the additional load. I realize that competition from Eiffel (which has parameterized types and multiple inheritance) is tight, but Eiffel provides somewhat more in the way of software tools for dealing with the extra complexity, and, thought I've never used Eiffel, I'm not convinced that these tools would make much of a difference anyway, since the runtime environment in Eiffel is also fairly impoverished with respect to languages like Smalltalk and Lisp. Somebody ought to look into a formal semantics, whether algebraic, denotational, or abstract is irrelevent, of C++. With that in hand, the effect of an addition like parameterized classes can be better assessed. Jim Kempf kempf@hplabs.hp.com
bs@alice.UUCP (10/01/87)
In article <1096@g.gp.cs.cmu.edu>, dld@g.gp.cs.cmu.edu (David Detlefs) writes: > > How do inheritance and parameterized classes interact? and Jim Kemph kempf@hplabsz.UUCP (kempf @ Hewlett-Packard Laboratories) adds a couple of warnings: > C++ is already a fairly rich language, and addition > of other constructs may push it over the brink. and > Somebody ought to look into a formal semantics, whether algebraic, > denotational, or abstract is irrelevent, of C++. I like the idea of parameterized types, I am quite concerned about complexity, I am (together with colleagues) trying find a more precise specification of C++. Whatever I do, I will definitely heed Jim's most important remark: Be careful! One source of trouble is of course that a more common attitude among users is I want it yesterday! Let me just mention a few questions: Why don't we just add multiple inheritance, full dynamic types, parameterized types, exception handling, concurrency features, persistent objects, statements as expressions, garbage collection, and the ability to defined arbitrary new operators? Why don't we have an integrated C++ environment? Why don't we have a large standard library like Smalltalk has? Why don't we stop worrying about compiler size, about complexity, about compiler speed, about run-time efficiency, about memory utilization, and (especially) about bad old linkers? Why don't we stop worrying about compatibility? It is no exageration to say that I hear every one of these every week. There are of course more such questions. To ensure that C++ a remain a stable, well defined, efficient tool for program development we must move relatively slowly and carefully. C++ isn't (just) a research toy/tool. Trying to do everything at once would be a disaster and doing anything significant well will take longer than most people are willing to believe. So, why don't we just leave C++ alone? Because we can do better - MUCH better - (without compromising compatibility, efficiency, portability, etc.) and because if we stopped now C++ would fragment into many incompatible dialects as everyone added their favorite extension and there were no mainstream to feed the ideas and experiences back into. C was essentially ``frozen'' by the publication of K&R; this will not happen to C++. Pascal splintered into dialects because necessary work wasn't done; this is harder to avoid now that there a many groups developing C++ compilers and tools, but need not happen to C++.