Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!labrea!aurora!ames!ptsfa!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uiucdcsp!johnson
From: johnson@uiucdcsp.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: addition
Message-ID: <80500014@uiucdcsp>
Date: Mon, 24-Aug-87 10:12:00 EDT
Article-I.D.: uiucdcsp.80500014
Posted: Mon Aug 24 10:12:00 1987
Date-Received: Wed, 26-Aug-87 06:07:19 EDT
References: <245100011@orstcs>
Lines: 23
Nf-ID: #R:orstcs:245100011:uiucdcsp:80500014:000:1309
Nf-From: uiucdcsp.cs.uiuc.edu!johnson    Aug 24 09:12:00 1987


It is true that double dispatching will take n^2 methods in the worst
case.  However, either these methods will mostly be different, in which
case you would have to have a method somewhere that was checking the
case of the argument and doing the appropriate thing, or they will be
mostly the same, in which case inheritance should greatly reduce the
number of methods.  For example, the addFraction method in Number could
be inherited by both Float and the various Integer classes with no
change.

However, I think that the real problem with double dispatching is a user
interface problem.  We need tools that will let us easily examine a
single method definition in a set of classes.  The "browseImplementersOf"
tool in Smalltalk-80 is not enough, because it only shows the methods
that have already been defined, not the classes that still need definitions.
Given such a tool, it would be trivial to add a large number of simple
methods to a set of classes.

The major problem with generality is that it is not general enough.  I think
that matrices were the class that caused Kurt Heeble to rewrite the number
classes.  I'll try to get him to comment.  There are other complaints I could
make against generality, such as the fact that it is slow and ugly, but those
are mostly a matter of personal opinion.