Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!rpi!uupsi!sunic!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.misc
Subject: Re: Runtime Polymorphism -- To Have and Have Not (Par
Message-ID: <2741@enea.se>
Date: 4 Mar 91 22:14:45 GMT
References: <559@coatimundi.cs.arizona.edu>
Organization: Enea Data AB, Sweden
Lines: 37

Also sprach David Gudeman (gudeman@cs.arizona.edu):
>There are several advantages to this.  First, it makes program
>prototyping and developement much faster because declarations are
>minimized.

Hm, I don't have the figures here, but which phases takes
most time in the life of a software product? Prototyping?
Development? Testing? Integration? Maintenance? I could
be wrong, but I don't think it is the prototyping and
early development stages when you could sneak some typing
time with shorter declarations. But the test and integration
phase will take longer time. Maintenance and support will
be more expensive. (Particulary support since you are
likely to get more crashes due to typing errors and similar.)

>Another advantage of runtime polymorphism is code generality.  You can
>write generic procedures that work on many data types (as long as it
>only makes use of operations that have definitions for all the data
>types).  For example you can write a procedure to insert something in
>a tree without knowing the type of the object: (Icon code)
>...
>The only operations on x are object comparison (<<<) and inserting
>into a record, so the procedure is entirely generic.  (As an aside,

Fine. I can do this in Ada and Eiffel. And assure at compile time, 
that I don't pass incomparable or uninsertable types to the generic 
routine.

>But in my experience this is a minor
>problem, and the time spent looking for these errors is quite small
>compared to the time that would have been spent writing strongly typed
>declarations.

You've tried this in 500.000 line system? What did the customers
say?
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se