Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!network!ucsd!orion.cf.uci.edu!uci-ics!zardoz!ccicpg!cci632!rit!tropix!moscom!ur-valhalla!uhura.cc.rochester.edu!rochester!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson From: johnson@p.cs.uiuc.edu Newsgroups: comp.sw.components Subject: Re: Inheritance vs. component efficienc Message-ID: <130200005@p.cs.uiuc.edu> Date: 22 Jul 89 20:27:00 GMT References: <5682@hubcap.clemson.edu> Lines: 52 Nf-ID: #R:hubcap.clemson.edu:5682:p.cs.uiuc.edu:130200005:000:2500 Nf-From: p.cs.uiuc.edu!johnson Jun 16 15:27:00 1989 Bill Wolfe is right -- I believe the following two things: 1) It is fairly unlikely that any particular component will fit the application developer's requirements, hence they must be rapidly modifiable as with inheritance. For some reason, using a tool which automatically constructs a higher level of abstraction (for appropriate modification) isn't appropriate, even though this also isolates the specification from the implementation. 2) For some reason, run-time binding is necessary. As far as the third goes, I think that diddling with old code is a necessary evil, but should be avoided where possible. We need to make reuse systems that let us leave old code along. > ... In general, > either a component is readily available (mostly the case), or it > gets invented on the spot. That's because you have no alternative. Inheritance makes a new alternative, invent a component by reusing most of the design of an existing one. I find that user interface tool-kits provide 95% of the components that I need. In a small program, they might provide everything I need. However, in a large program most of my time goes to building the 5% of the components that don't exist. Inheritance makes that 5% easier. > 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. As I said before, I think that this is a good idea. It is essentially inheritance. > I don't perceive any need for run-time binding. Consider a windowing system. A big window can contain smaller windows. Each window can display itself. A large window displays itself by displaying its smaller windows. It would have an array of subwindows, and would iterate over them, performing the DISPLAY operation on each one. However, since different subwindows display different kinds of things, there must be run-time binding. In a conventional language this would be implemented by case statements. However, case statements result in code that is much less reusable, since adding a new kind of window requires adding a new case to a whole bunch of case statements. You could implement an object-oriented Ada with a preprocessor by rewriting late-bound procedure calls into case statements. In this case, your preprocessor would be automatically maintaining the case statements. Ralph Johnson