Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!shelby!rutgers!ncs.dnd.ca!dal From: dal@ncs.dnd.ca (Andyne) Newsgroups: comp.object Subject: Re: Do we really need types in OOPL's? Message-ID: <1990Oct5.212947.19003@ncs.dnd.ca> Date: 5 Oct 90 21:29:47 GMT References: <1990Oct2.170910.4805@eua.ericsson.se> <1990Oct5.010703.16019@Neon.Stanford.EDU> Sender: Diptendu Dutta Organization: Andyne Computing Limited Lines: 29 In article <1990Oct5.010703.16019@Neon.Stanford.EDU> craig@Neon.Stanford.EDU (Craig D. Chambers) writes: 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. The problem is that "making guarantees about type safety efficiently at compile time" requires the use of the anti-monotinicity or contra-variant rule (used in Trellis/Owl, Emerald, Duo-Talk, and many other languages for checking `conformance') which DOES overly constrain the kinds of programs people can write (even the most intuitive subtype relationships do not hold). The other alternative is to claim that "PRACTICAL SOFTWARE ENGINEERING does not require the contravariant rule 95% of the time (even though novices might easily come up toy examples where type failures occur without it), the flexibility offered by the covariant rule in defining subtype relations is worth more than the inability of guaranteeing type safety for 5% of the cases at compile time", and create kludgy checks to handle the 5% case in an unsatisfactory manner. Diptendu Dutta Andyne Computing Limited 544 Princess Street, Suite 202 Kingston, Ontario, Canada K7L 1C7 (613) 548-4355 diptendu@andyne.dnd.ca