Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!decwrl!shelby!neon!craig From: craig@Neon.Stanford.EDU (Craig D. Chambers) Newsgroups: comp.object Subject: Re: Do we really need types in OOPL's? Message-ID: <1990Oct5.010703.16019@Neon.Stanford.EDU> Date: 5 Oct 90 01:07:03 GMT References: <3832@osc.COM> <1990Oct2.170910.4805@eua.ericsson.se> Organization: Stanford University Lines: 66 In article cline@sun.soe.clarkson.edu (Marshall Cline) writes: >In article <1990Oct2.170910.4805@eua.ericsson.se> euaabt@eua.ericsson.se (Anders.Bjornerstedt) writes: >>Strong typing is not the same thing as static typing. > >From the rest of your remarks, I *think* we agree in concept, but the >terminology you use is perhaps non-standard. Strong typing *DOES* mean >static typing [ex: Booch OOD, Meyer OOSC, etc]. It does not necessitate >static *binding*, as I and others have repeatedly said. > >>Magnus Ramstr|m talks >>about strong typing and you then go on and talk about static typing. >>An example: In Simula you have the notion of requalification, which is like >>casting in C or C++ but causes a runtime check. [...] > >Although this is `type safe', it is not statically typed (strongly >typed). Like pointer coersions in C++, this is a hole in Simula's >strong type system (put there intentionally for very good pragmatic >reasons; real life software engineering isn't always as pretty as >Pascal). Pointer coersions in C++ aren't type *safe*, but neither >they nor Simula's requalification is statically typable in general. I disagree with your terminology. Strong typing means that all operations are type safe; static typing means that type safety can be guaranteed statically by scanning the program text. Most dynamically-typed languages (i.e. languages that do not type check programs statically but instead defer any necessary type checks until run-time) are strongly typed (e.g. Lisp (at least interpreted versions), Smalltalk, Self), since the run-time system ensures that only legal (type safe) operations are applied to objects/values. Many statically-typed languages are also strongly typed. Some languages are mostly statically-typed, but include facilities/loopholes to defer type checking until run-time (e.g. Simula and CLU). Other languages claim to be statically- and strongly-typed, but in fact contain holes in the type system that can lead to violation of type safety (e.g. Eiffel, Beta (I believe)). Other statically-typed languages aren't strongly-typed at all (e.g. C, C++); these are usually called weakly-typed languages. Since strong typing and static typing are frequently misused as synonyms, I tend to avoid using the terms strong and weak typing without including a definition of what I mean. Luckily, static typing is pretty well universally understood to mean what I think it means. Completely orthogonal to static vs. dynamic and strong vs. weak typing is static vs. dynamic binding, sometimes called early and late binding. Languages with dynamic binding include some sort of run-time dispatching to select an appropriate implementation for a procedure call based on the run-time values of the call's arguments. This implementation may be indirect procedure calls ala C++, hash table lookups ala Eiffel and Smalltalk, or some other implementation. Of course, in some situations the compiler may be able to find the single matching implementation for a dynamically-bound call and thus reduce it to a statically-bound call as an optimization (e.g. using type analysis and customization in Self or using case analysis in Typed Smalltalk), but in general this can't always be done. To answer the original question about types in OOPLs, then, I think that there is a place for static type information in object-oriented programs. The trick is to design a type system that both supports making guarantees about type safety efficiently at compile-time and doesn't overly constrain the kinds of programs people can write. Using abstract interfaces/signatures/specifications as types is a good way to do this. See Ralph Johnson's earlier posting for a good discussion of the relationship between types and classes. -- Craig Chambers