Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!ut-sally!utah-cs!shebs
From: shebs@utah-cs.UUCP
Newsgroups: comp.lang.misc
Subject: Re: OBJ2 and Smalltalk
Message-ID: <4286@utah-cs.UUCP>
Date: Tue, 10-Feb-87 11:16:23 EST
Article-I.D.: utah-cs.4286
Posted: Tue Feb 10 11:16:23 1987
Date-Received: Wed, 11-Feb-87 18:55:58 EST
References: <4000001@nucsrl.UUCP> <3288@milano.UUCP>
Reply-To: shebs@utah-cs.UUCP (Stanley Shebs)
Organization: University of Utah CS Dept
Lines: 36
Keywords: Useful queues?

In article <278@figaro.STANFORD.EDU> asente@figaro.UUCP (Paul Asente) writes:
>...it is not polymorphism
>that I find questionable, it's unbounded polymorphism.
>...What I find of dubious usefulness
>and even more dubious stylistic practice even if it were useful is
>creating a data structure having no idea of what goes into it.  Can
>you actually think of an example where you would want a queue that
>allowed you to enqueue absolutely anything?  If you know what's going in,
>it may be more convenient to program it with no element type checking
>than to set up subtypes of the queue elements for the types you know
>are going in, but is it really good style?

I was using examples from heavily engineered production software;  in those
circumstances I agree that there is little use for "unbounded" polymorphism
(is there a technical term for that?).  In ten years of looking at "real"
software, I have not seen any cases where unbounded polymorphism was either 
used or where it would have been the right thing.

On the other hand, unbounded polymorphism is essential to a good development
environment.  It's an extremely important abstraction tool - my just-written
procedure will take anything as an argument and pass it on somewhere else;
I can wait till later to decide what kinds of things actually pass through.
If I need to make a change, only the actual generators and consumers of an
object must be hacked.  Ultimately I may determine that only numbers appear
in a given context, at which point (at least in Common Lisp) I can add
appropriate declarations.  It's a straightforward tradeoff between constraint
and flexibility.  Even after development, Lisp and Smalltalk programmers tend
to avoid sacrificing flexibility, so as to ease maintenance and enhancement.
Stylistically, I don't think there's a problem, because the whole point of
style is to facilitate reading, and I find it easier to read code if the types
of most entities in the program are irrelevant to its correct behavior.
(On aptitude tests, I scored very very low in "clerical skills").

>	-paul asente

								stan shebs