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: <285@suadb.UUCP>
Date: Mon, 6-Jul-87 09:04:33 EDT
Article-I.D.: suadb.285
Posted: Mon Jul  6 09:04:33 1987
Date-Received: Sat, 11-Jul-87 01:23:50 EDT
References: <245100009@orstcs> 
Reply-To: anders@suadb.UUCP (Anders Bj|rnerstedt)
Organization: University of Stockholm, Sweden
Lines: 40

In article  bmc@argus.UUCP (Bob Czech) writes:
>
> In article <245100009@orstcs>, budd@orstcs.cs.ORST.EDU writes:
> > 
> > 4. Types are considered as part of the message pattern for the purposes of
> > method lookup.  (This is an extension of object message lookup, where the
> > types of arguments other than the first may also be important).  This would
> > seem to be the most general solution, since the only overhead involved is
> > that of method lookup, not argument checking, and tricks such as caching
> > can be used to speed up message lookup.  Never the less, the Smalltalk
> > notion of class is not the most useful concept of type that could be
> > envisioned, and again this limits polymorphism.
> > 
>
>	I see it as a way of cutting out the run time overhead of a message
>lookup with typing of variables.  In this way the exact method is bound to the
>variable during compile time.  There is no need for a message lookup at runtime
>because you have the class of the recevier already specified.

Typing may be used by the compiler to make early binding (binding to
the concrete type you might say) in order to gain efficiency. However
you then exclude polymorphism. You may still want typing AND late 
binding (binding to the abstract type you might say) in order
to have both flexibility (polymorphism) and security, i.e. the
object is guaranteed to support a certain protocol.

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

  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