neil@comp.lancs.ac.uk (Neil Haddley) (08/10/88)
All,
This mail is a request for an informed opinion on what is to me a
complex issue. What I hope will result is a generally accepted position
of the form:
"The majority of regular Smalltalk programmers would agree that ..."
The point at issue:
"The Inheritance mechanism of Smalltalk and other Object-Oriented
programming languages provides significant support for code level
Software Reuse"
My current tentative opinion is that this is in fact not the case.
Although it does allow for nice structuring of code, through the use of
Abstract Classes etc, it does not provide any advantage over other code
level reuse mechanisms, such as Generic Abstract Types.
Comments would be welcome, and I will post any interesting results on
the net, thank you.
Neil
--
EMAIL: neil@comp.lancs.ac.uk | Post: University of Lancaster,
UUCP: ...!mcvax!ukc!dcl-cs!neil | Department of Computing,
| Bailrigg, Lancaster, UK.jmaloney@june.cs.washington.edu (John Maloney) (08/16/88)
Neil,
I believe your question was:
"Does the inheritance mechanism of Smalltalk and other Object-Oriented
programming languages provide significant support for code level
Software Reuse?"
rather than:
"Does inheritance have *unique* advantages over other mechanisms supporting
software reuse, such as generic abstract types?"
I believe the answer to the first question is defintely, yes, inheritance
supports code reuse. I am not sure if it has any advantage over generic
abstract types from the standpoint of code reuse. However, it is
useful when one wants to experiment with a
change to some system class which could potentially have high impact
on many diverse parts of the system. One can instead perform one's experiments
on a new subclass, thus confining the potential damage caused by a mistake.
For example, suppose you wanted to change the behavior of the basic
system-supplied windows ("views" in Smalltalk). If one changed the relevant
system class directly and made a mistake, the system would try to open
a debugger window. However, doing this would encounter the same error
in the window code. This new error would cause the system to try to open
a debugger window and... You would have an infinite recursion which
would crash the system!
Now, if you didn't have inheritance, you'd have to copy all the code for
the system class in question, re-name it, and perform experiments on the
copy. This is certainly not as quick as making a subclass and adding one
or two methods. In addition, using subclassing makes your changes explicit.
Hope this helps.
-- John Maloneysdl@linus.UUCP (Steven D. Litvintchouk) (08/21/88)
In article <550@dcl-csvax.comp.lancs.ac.uk> neil@comp.lancs.ac.uk (Neil Haddley) writes: > The point at issue: > > "The Inheritance mechanism of Smalltalk and other Object-Oriented > programming languages provides significant support for code level > Software Reuse" > > My current tentative opinion is that this is in fact not the case. > > Although it does allow for nice structuring of code, through the use of > Abstract Classes etc, it does not provide any advantage over other code > level reuse mechanisms, such as Generic Abstract Types. Disagree. Read the paper, "Genericity vs. Inheritance," by B. Meyer (OOPSLA '86). The nice thing about inheritance is that one can do "differential programming." That is, each newly designed abstraction can inherit all the code of a previous abstraction, but also contain some modifications or enhancements. Abstractions can be made to smoothly evolve from one another; and each intermediate form along the evolutionary path is available for future reuse. I have been programming in Ada, developing generic abstract types, for about 5 years. The problem with generics is that differential programming is difficult. If you want to develop a generic (parameterized) ADT, you must decide a priori what the generic parameters are. Once you have done this, all you can do is instantiate the generic in various ways. If you decide later that the generic ADT needs further modification to support reuse, then you must either: -- physically modify the ADT code to add additional generic parameters (probably invalidating all your existing instantiations). -- develop a new generic ADT (with additional generic parameters), based on the existing generic ADT. But the new generic ADT must also have all the original generic parameters from the original ADT. In either case, the number of generic parameters thus tends to grow over time; I've got Ada generics with twenty or thirty generic parameters! Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 Fone: (617)271-7753 ARPA: sdl@mitre-bedford.arpa UUCP: ...{cbosgd,decvax,genrad,ll-xn,mit-eddie,philabs,utzoo}!linus!sdl "Those who will be able to conquer software will be able to conquer the world." -- Tadahiro Sekimoto, president, NEC Corp.