Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!nbires!hao!hplabs!tektronix!reed!mdr From: mdr@reed.UUCP Newsgroups: net.lang.st80 Subject: Re: Typed Smalltalk Message-ID: <3886@reed.UUCP> Date: Sun, 20-Jul-86 19:32:08 EDT Article-I.D.: reed.3886 Posted: Sun Jul 20 19:32:08 1986 Date-Received: Mon, 21-Jul-86 06:07:36 EDT References: <799@cit-vax.Caltech.Edu> <9000007@uiucdcsp> Reply-To: reed!tektronix!BAtkinson.pa@Xerox.arpa (Bob Atkinson) Organization: Xerox Parc NW, Portland, Oregon Lines: 35 Summary: Expires: Sender: Followup-To: In article <9000007@uiucdcsp> johnson@uiucdcsp.CS.UIUC.EDU writes: >Even if the compiler performs some optimizations, it will still have >to implement some Smalltalk programs pretty much the same as it does >now, using method look-up. ... at least if the code wasn't doing what the compiler thought it would do when it compiled the code. One the biggest wins of a ST type system will be the ability to eliminate many of the dynamic method lookups that occur, at least if the programmer has hinted the compiler in the right direction. >> What if I wanted to >> make a subclass of ByteArray that masqueraded as a Float but had >> infinite precision (similar to LargeIntegers) - would this be a type >> clash, or would I have to cast the LargeFloat as a regular Float? > >The subclass of ByteArray is not a Float. However, it acts like a Float. >You should not usually write code that requires objects to be in a >particular class. Instead, you should require that objects have certain >behavior. That's of course true, and it points to one of the hardest problems in adding a type system/optimizing compiler to ST. To do any reasonable amount of optimization, one needs to get rid of many dynamic method lookups, and to do this necessitates finding the actual code executed by other message sends. This requires knowing the classes of message receivers, since this is what descriminates the method executed at run-time. This is why every ST type system that I have heard of has been class/set of classes oriented. This is in conflict with the progamming practice of ``progamming by protocol'', that is, not caring about classes per se, but only on the messages responded to. -bob atkinson BAtkinson.pa@Xerox.com