Path: utzoo!attcan!uunet!wuarchive!sdd.hp.com!usc!apple!lins From: lins@Apple.COM (Chuck Lins) Newsgroups: comp.object Subject: Re: Do we really need types in OOPL's? Message-ID: <46015@apple.Apple.COM> Date: 26 Oct 90 18:09:04 GMT References: <2444@runxtsa.runx.oz.au> <45940@apple.Apple.COM> <1990Oct25.131653.13463@cbnewsc.att.com> Organization: Apple Computer Inc., Cupertino, CA Lines: 49 In article <1990Oct25.131653.13463@cbnewsc.att.com> lgm@cbnewsc.att.com (lawrence.g.mayka) writes: >In article <45940@apple.Apple.COM>, lins@Apple.COM (Chuck Lins) writes: >> In article <1990Oct19.180646.8649@ux1.cso.uiuc.edu> render@cs.uiuc.edu (Hal Render) writes: >> >Assuming that any software you write is thoroughly tested, most >> >type errors that would be caught at compilation can be caught during >> >testing. >> >> First, "most" is not the same as "all". Second, you may be forgetting the >> relative costs here. A compilation of a few seconds (or even minutes) costs >> far far less than the hours or days it takes to thoroughly test software. We >> are talking orders of magnitude here. > >First, your cited costs are system-dependent. For some software >systems recompilation takes hours or days, but incremental testing >takes seconds or minutes. Monolithic systems written in C and Pascal have serious problems with recompilation. Change a comment - recompile the system :-) Which is why I personally never use them anymore. Separate compilation has been around for too many years to remember. Information hiding helps here too (as in Modula-2, Ada, etc). Incremental testing is also system-dependent. Your example of a large system that takes days to recompile certainly cannot be adequately tested in minutes or seconds. I do incremental compilation oand testing all the time. These features seem to me more a function of the development environment than of the language. But that's not part of the type discussion :-) [accidentially deleted relavent comments about the restrictions of types] I agree that it's better not to limit types based on internal representation al details. Rather that semantic capabilities are more important here. This seems to me similar to the 'type conformance' idea in the Emerald system (if it's not the same thing). But this is still the concept of a type. A 'kinder, gentler' type, but a type nonetheless. The only problem is capturing the correct semantics for operations. What I'm trying to say (and doing it poorly) is that "+" for numeric quantities means something very different from "+" for strings (concatenation). Trying to "+" a number and a string may not have any semantic meaning even though both objects have an operation called "+". (Yes, we can postulate meaning for this specific instance; I'm reasonably certain that there are situations where we couldn't, or everyone would disagree. Thought I'm willing to be convinced otherwise :-) -- Chuck Lins | "Is this the kind of work you'd like to do?" Apple Computer, Inc. | -- Front 242 20525 Mariani Avenue | Internet: lins@apple.com Mail Stop 37-BD | AppleLink: LINS@applelink.apple.com Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist" The intersection of Apple's ideas and my ideas yields the empty set.