Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!sri-spam!parcvax!susser
From: susser@parcvax.Xerox.COM (Josh Susser)
Newsgroups: comp.lang.smalltalk
Subject: Re: addition
Message-ID: <450@parcvax.Xerox.COM>
Date: Mon, 24-Aug-87 22:03:31 EDT
Article-I.D.: parcvax.450
Posted: Mon Aug 24 22:03:31 1987
Date-Received: Thu, 27-Aug-87 05:53:49 EDT
References: <245100011@orstcs>
Reply-To: susser@parcvax.xerox.com.UUCP (Josh Susser)
Organization: Xerox Special Information Systems, Pasadena, CA
Lines: 29
Summary: Slander! Libel! I'll sue!

[choke on this, line eater!]

In <245100011@orstcs> budd@cs.orst.edu (Tim Budd) writes:
>But, as Josh Susser at parkplace said:
>>  ...  Who really cares what
>>  class an object is as long as it behaves correctly anyway?

Well, Tim, I'll be the first to admit that I did in fact say just that.
However, I do not work for ParcPlace Systems. I work in the Smalltalk
applications group at Xerox Special Information Systems in Pasadena, CA.
We have been writing Smalltalk applications here since the time of
Smalltalk-76. If I'm going to work at a place nobody knows about, I'm going
to make darn sure everybody knows it! :-)

Back to the discussion at hand: seems to me like the numeric coercion
mechanism is a nice way of dealing with the problem WITHOUT explicitly
testing the class of an object. All you need to do to implement a new Number
subclass is to make sure it responds to the proper protocols and assign it a
generality - nowhere is it necessary to put special case code in other Number
subclasses to handle the coercions. The biggest drawback to this approach is that
it is much slower that using mulitiple polymorphism. I think the generality and
ease of expandability more than makes up for the performance hit. But that's
what I think of Smalltalk in general.

-- Josh Susser
   Xerox Special Information Systems
   Susser.pasa@Xerox.com

You may be a vampire, but you're still my brother.