Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!enea!suadb!anders
From: anders@suadb.UUCP (Anders Bj|rnerstedt)
Newsgroups: comp.lang.smalltalk
Subject: Re: declarations vs smalltalk
Message-ID: <284@suadb.UUCP>
Date: Sat, 4-Jul-87 11:34:47 EDT
Article-I.D.: suadb.284
Posted: Sat Jul  4 11:34:47 1987
Date-Received: Sun, 5-Jul-87 06:35:50 EDT
References: 
Reply-To: anders@suadb.UUCP (Anders Bj|rnerstedt)
Organization: University of Stockholm, Sweden
Lines: 49

In article  budd@orstcs.cs.ORST.EDU writes:

>
>2. The Pascal philososphy - declarations are all checked statically at some
>point long before run time.  Either requires declarations everywhere (too
>restrictive and limits polymorphism) or requires extensive data flow
>analysis (complicated).

Declarations (which  may be checked statically) certainly limit
polymorphism, that is the whole point of typing. However declarations
do not exclude polymorphism, as long as the actual (run-time) value
is of a type satisfying the formal declaration, e.g. the value is 
of the same type or a   subtype of the  declaration, then the
expression is type correct. 


>3. Hidden code is created to check the conformability of argument types
>with declarations prior to method execution.  Why is this any more
>efficient than user written code to do the same task?  Allowing the user to
>do it would seem to be more flexible.  And what happes when the
>declarations are violated?  Does the user have any recourse?

Why use high level  languages at all ? Compiler generated  run-time
checks are less errorprone, code easier to maintain.

>In short, there seems to be an implicit conflict between strong typing, or
>typing of any sort, and polymorphism.  Strengthing one limits the other.

I agree that there is a trade-of involved.
Typing can be seen as the limitation of polymorphism 
(though not the elimination of polymorphism). This is at the
expense of flexibility but for the benefit of security. Depending
on the size of a software project or the number of individual 
programmers involved this will be more or less important.

  ---------------------

  Anders Bjornerstedt
  Department of Information Processing & Computer Science
  University of Stockholm
  S-106 91  Stockholm
  Sweden


UUCP:{seismo,mcvax,cernvax,diku,ircam,prlb2,tut,ukc}!enea!suadb!anders
ARPA: enea!suadb!anders@seismo.arpa