🚀 go-pugleaf

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