Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!hubcap!billwolf%hazel.cs.clemson.edu From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.sw.components Subject: Re: Inheritance vs. component efficienc Message-ID: <5740@hubcap.clemson.edu> Date: 11 Jun 89 20:26:43 GMT References: <5186@pt.cs.cmu.edu> Sender: news@hubcap.clemson.edu Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu Lines: 105 From article <5186@pt.cs.cmu.edu>, by ram@wb1.cs.cmu.edu (Rob MacLachlan): > As I see it, the key barrier to reusing software is that systems don't > naturally break down into atomic reusable components. While out in industry, I found the reverse to be true; as long as one actively seeks to identify reuseability opportunities, there will be little difficulty finding them. Just about anything you do more than once is a good candidate for reuseability, after being structured into an appropriate abstraction. The problem is not that "systems don't naturally break down into atomic reuseable components"; in fact, they do so quite readily when considered in relation to similar systems. The problem is that many programmers (and project managers) do not view things with an eye toward reuseability; programmers either because their language doesn't support reuseability or because the concepts are slow to propagate into industry, and managers because they aren't being measured by anything other than the time and money required for the project itself, regardless of the potential value of spinoffs. > Supposing I had this whizzy indexed library of frobs, and I wanted > a green frobboz. But when I look, I probably won't find one. I could > maybe make do with the yellow-green one, but I would have to work around > it or modify it. The advantage of an o-o inheritance system is that it > makes it very easy to reuse a component *with modifications*. If you have > to modify a component without understanding how it works, then you are much > better off with the structured modification techniques of inheritance and > method combination than if you attempted arbitrary modification of the code. The same thing is possible through the use of Ada packages; a new package serves as an interface which hides both the calls to the old package and the new code which was added on top of it, thus preserving the integrity of the original abstraction and creating a new one. Do you seriously believe that any software engineer worth his/her pay is going to overlook the above strategy? Quite simply, "Abstraction is the fundamental means by which the computer scientist can combat complexity"; to assume arbitrary modification of code is to assume total disregard for this fundamental principle of computer science. Now if a single inheritance clause is used to obtain both specification and implementation, it would seem that any modification of a component's implementation would trigger the recompilation of everything depending on it. In contrast, the new Ada package can be added to the local library of software components immediately if it seems appropriate; when it becomes obvious that the component is going to have to be implemented more efficiently, Ada provides the abstract separation which allows us to replace the implementation in a modular fashion without recompiling any of the code depending upon the abstraction. The Ada package provides excellent support for abstraction, and it has yet to be demonstrated that inheritance is even necessary. > I personally think you are wacko if you think that there are going to be > very many components reusable millions of times without modification, at > least if defined in Ada. Why? Ada provides a very high level of support for abstract data types, so no problems there. There is a large and growing set of Ada packages which support specific domains (the classic math libraries are the basis for this increasingly important reuseability strategy), which extend reuseability into reuseable domain-specific knowledge; they certainly work rather effectively. What basis is there for claiming otherwise? > I can conceive of there being a "programming environment" someday that > could substantially automate the process of customizing components, but > it's going to have to pay a lot more attention to semantics than Ada does. The knowledge-based reuseability librarians discussed earlier in this newsgroup (Unisys STARS research) substantially automate the process of selecting existing components. When a component requires customization, it is conceivable that a knowledge-based customizer could make use of the same knowledge base used by the librarian to create an interface package appropriate for a particular user, while alerting component developers when a given modification is requested frequently enough to warrant efficient implementation. But these are AI topics which are largely independent of the underlying language. Unlike C++ and other "moving targets", Ada is the product of a language *engineering* effort. Users are assured of linguistic stability for ten years at a time, long enough for investments in the language to pay off. Ada 83 software will almost certainly be suitable for automatic Ada 9X translation, thus ensuring the continuity of that investment. In the interim between revisions, opportunities exist to incorporate new ideas which emerge in the form of research languages, if they make a significant new contribution and can be efficiently implemented; but so far, inheritance isn't holding up very well on either count. When we consider that Ada was designed in the late 70's (it took from 1980 to 1983 to get Ada through the ISO), its continuously accelerating popularity almost a decade later is quite remarkable, and a strong affirmation of the vision and skill of its designers. The concepts developed in _Abstraction_Mechanisms_And_Language_Design_ (Paul N. Hilfinger's ACM Distinguished Dissertation) will surely lead to an even higher level of support for the process of abstraction as Ada upgrades itself to support the 1990's. Nevertheless, given that support for secure data abstractions which can survive external multitasking as well as utilize multitasking internally, in conjuction with the no subsets, no supersets, ten-year stability essential for portability and for a software components industry, is still the exclusive domain of Ada 83, and that much research still needs to be done on ways to fully exploit parallelism in the implementation of abstract data types, it is quite clear that Ada 83 is a very powerful tool whose limits are much farther away than the limits of our current ability to fully utilize its capabilities. Bill Wolfe, wtwolfe@hubcap.clemson.edu