Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.object
Subject: Re: Inheritance explained... finaly...
Message-ID: <14185@lambda.UUCP>
Date: 8 Jan 90 22:26:04 GMT
References: <1130005@gore.com>
Lines: 56

From article <1130005@gore.com>, by jacob@gore.com (Jacob Gore):
> IEEE Spectrum, January 1990.  Cover topic: "Technology '90".  [...]
> "Object-oriented programming a hit" by Ted G. Lewis ("Expert Opinion").
> 
> 	Suppose, for example, a program is to process complex
> 	numbers consisting of real and imaginary parts.  In a
> 	complex number, the real and imaginary parts behave like
> 	real numbers, so all of the operations (+, -, /, *,
> 	sqrt, sin, cos, etc.) can be inherited from the class of
> 	objects called REAL, instead of having to be written in
> 	code.  This has major impact on programmer productivity.

In fact, I always use Complex numbers to demonstrate the some of the
problems which still plague Object-oriented languages.

For example, on my SmallTalk system the class heirarchy for numbers
is:

                        Object
                          |
                      Magnitude
                       /     \
                     Time   Number
                     Date   / | \
                           /  |  \
                     Integer  |  Float
                           Fraction

Obviously, I can't make Complex a subclass of number because complex
numbers aren't well ordered (and are, therefore, not Magnitudes).
Similarly, I can't rearrange the heirarchy an place Magnitude under
Number since I don't want the arithemtic operators defined on such
things as Time and Date.  Some Object-oriented languages are now
correcting this problem by allowing multiple inheritance - but not
without new problems.

Second example: Complex numbers show a weekness in Object-oriented
languages with respect to encapsulation.  This is because of the
concept of 'messages'.  For some applications, it is perfectly
reasonable (even desireable) to have _functions_ be asymmetrical
in their arguments.  But, for other applications, it is completely
unnatural.  In this case, it is necessary to modify the definitions
of the Integer, Float, and Fraction classes in order to implement
the expected mixed-mode operations on Complex.  This violates the
spirit of the Object-oriented language with respect to excapsulation.
Of course, many Object-oriented languages don't use message passing
syntax - and even some that do also offer overloading of operators
as a separate mechanism from message passing.  It should, after all,
be possible to define Complex as a single class without altering
any other classes to handle it.

In any case, I still have doubts about the future of Object-oriented
programming.  After all, except for inheritance, the whole concept
is a subset of what can be done with generic functions and overloading.
Maybe the correct approach is to add inheritance to a language which
has generic functions - it can't be THAT hard.