Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!rutgers!cmcl2!lanl!opus!ted From: ted@nmsu.edu (Ted Dunning) Newsgroups: comp.sw.components Subject: Re: Inheritance vs. component efficienc Message-ID: Date: 15 Jun 89 17:39:33 GMT References: <130200003@p.cs.uiuc.edu> <5769@hubcap.clemson.edu> Sender: news@nmsu.edu Organization: NMSU Computer Science Lines: 72 In-reply-to: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu's message of 14 Jun 89 21:37:04 GMT there seems to be a collision of programming styles going on in this group. in particular, the edit/compile camp insists that run-time flexibility is not really needed since most of the work of instantiation and inheritance can be done at compile or edit time, while the interactive/run-time binding camp insists that this is not sufficient. in particular, william thomas wolfe puts the compile/edit side of the argument concisely when he writes Regarding 1), I have exactly the opposite perspective; in general, either a component is readily available (mostly the case), or it gets invented on the spot. Furthermore, in the very unlikely event that I need to slightly modify an existing ADT, a tool can be used to generate another level of abstraction and proceed from there. what he misses are the real reasons inheritance must be implemented in a more fundamental way than just a fancy editor. these reasons are parsimony in the source text, and flexibility in the program development phase. while it is true that having an editor write interface and implementation code effectively provides the necessary mechanisms of inheritance, this ignores the fact that the programmer is left with a LARGE mass of code to work with. anyone who has tried to write a new x-window widget that is only a trivial specialization of an old one can tell you that there is a HUGE amount of code that you have to learn to ignore. this overhead should be hidden from the programmer to simplify the reading of the code (even after you have learned to ignore huge chunks of stuff), and also to prevent inadvertent modification. secondly, having an inheritance mechanism built into the language will likely have the secondary consequence that the mechanism will be built into the debugges for the language. trying to debug an object oriented program without support from the debugger is similar to trying to use a debugger which does not support structure display. a debugger must avoid presenting the programmer with excessive detail as a default. Regarding 2) and 3), I don't perceive any need for run-time binding. Even if we were to define classes of types (characterized by the operations which it has available) and allow procedure parameters to be described in terms of such classes, this still would simply amount to a more readable version of "this procedure is generic in the type of this parameter; auto-instantiate as necessary after determining at compile time the type of the actual parameter". you can't be seriously saying the the equivalent of c++ virtual functions is not needed. it is crucial that you be able to pass around an object which is declared to be a relatively general object but which is in fact some unknown (to the code at run-time) specialization. if you aren't saying this, then you must be saying that the extent of genericity of a class can be determined at compile time. if so, consider a program that reads a textual description of objects to be instantiated. this is a simplification of what an interpreter for an object oriented language must do. how in a completely compile oriented environment can you provide consistent instantiation mechanism in this case? must you resort to the fabrication of an entire run-time class inheritance scheme from whole cloth? why is a language that requires this a good one? - of course, since no other language but ada is worthy, then the - simulation of object oriented languages is also not worthy :-)