Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!parcplace!khaw
From: khaw@parcplace.com (Mike Khaw)
Newsgroups: comp.object
Subject: Re: Inheritance explained... finaly...
Message-ID: <661@parcplace.com>
Date: 9 Jan 90 21:56:49 GMT
References: <1130005@gore.com> <14185@lambda.UUCP>
Organization: ParcPlace Systems, Mt. View, CA
Lines: 78

jlg@lambda.UUCP (Jim Giles) writes:

>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

The current version of ParcPlace's Smalltalk-80 (version 2.5) provides
a Complex class as a file-in.  The class hierarchy then looks like:

	Object
		Magnitude
			ArithmeticValue
				Number
					Fraction
					Integer
						LargePositiveInteger
						LargeNegativeInteger
						SmallInteger
					LimitedPrecisionReal
						Float
				Point
				Complex

>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.

ParcPlace's implementation of Complex makes use of version 2.5's
exception handling mechanism to raise an exception on attempts to send
comparison messages (e.g., "aComplex < bComplex").

As for Time and Date, I can imagine wanting to do arithmetic on
instances of them (in fact, I have an old Casio calculator that does
arithmetic on times and dates).

>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.

Double dispatching takes care of making binary operations commutative;
e.g., "2 + aComplex" conceptually results in the "+" method in
SmallInteger "failing", then turning things around and sending
"aComplex + self", since the "+" method of Complex implements adding
integers to complex numbers.  SmallInteger doesn't have to know
anything about Complex, Float, etc., it just has to know that the
argument to its "+" method is not something that it can handle, and
do the double dispatching.
-- 
Mike Khaw
ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043
Domain=khaw@parcplace.com, UUCP=...!{uunet,sun,decwrl}!parcplace!khaw