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