Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uwm.edu!bionet!parc!boehm From: boehm@parc.xerox.com (Hans Boehm) Newsgroups: comp.object Subject: Re: A Hard Problem for Static Type Systems Message-ID: Date: 29 Apr 91 17:41:04 GMT References: <1991Apr25.011607.25536@leland.Stanford.EDU> <3617@sequent.cs.qmw.ac.uk> Sender: news@parc.xerox.com Organization: Xerox PARC Lines: 34 eliot@cs.qmw.ac.uk (Eliot Miranda) writes: >In article you write: >>It's not entirely clear to me what you're trying to achieve by viewing >>integer and float as subtypes of number. They presumably share no code, >>hence code reuse is not the issue. >They most certainly can. In Smalltalk-80's arithmetic implementation >class Number provides a number(sorry) of arithmetic operators defined in terms >of other (presumed more primitve operators). >e.g. >Number abs > ^self < 0 ifTrue: [self negated] ifFalse: [self] > ... Certainly it is possible for them to share code using inheritance, once you augment the example with other functions. However the original < and min example also point out why you might not want to do this. Implementing min as a method of number means that ir only applies to numbers, and not to other objects understanding <. This argument is perhaps less convincing for abs, since there are fewer kinds of objects that understand 0, <, and negation. Other operations like integer exponentiation again have much wider applicability. The point is that inheritance is sometimes the right tool, but it often is not. For the original problem, I believe it is not. For some expansions of the original problem, it probably is. But even then there are static type systems (e.g. Cardelli's Quest) that deal with both parametrization and subtyping. Hans boehm@xerox.com Standard disclaimers ...