From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: David Hanley Subject: Re: OO, C++, and something much better! Date: 1997/01/27 Message-ID: <32ECF63D.5EB@netright.com>#1/1 X-Deja-AN: 212624227 references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> <5bphq4$5js@mulga.cs.mu.OZ.AU> <32E05FAF.47BA@concentric.net> <5buodl$bci@boursy.news.erols.com> <32E2FEC7.2F7B@concentric.net> <5bvncj$gqg$1@A-abe.resnet.ucsb.edu> <32E47B4B.56D9@concentric.net> <32E4E6E1.437E@dstsystems.com> <32E8C18F.354B@sdrc.com> content-type: text/plain; charset=us-ascii organization: netright technologies mime-version: 1.0 reply-to: david_nospam@netright.com newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object x-mailer: Mozilla 3.0Gold (WinNT; I) Date: 1997-01-27T00:00:00+00:00 List-Id: Mark Windholtz wrote: > > I'm sure most agree that finding and correcting problems > early is a good thing. Indeed. > The question is what kind of problems? > Dynamic languages let you test the logic more and > static languages (perhaps) let you test the interfaces more. I couldn't disagree more. I doubt that dynamic languages let you test logic more, while I definitely agree that static languages let you test interfaces more. I would argue that static langauges let you test logic more because you can embed the logic of your program into your type system. For example, a function that computes the containing rectangle of a polygon can return a rectangle, composed of four points. If you try to treat the return value differently in some way, you know right away, at compile time. > > I say "perhaps" because as soon as casting is added to > a program written in a static language, you lose the > testing of the interface. Only if you do unsafe casting, and such casiting is necessary. Static typing != C. > > And it is very hard to write interesting OO in a static > language without occationally casting. Again, static typing != C. It appears to me very often that in these static Vs. dynamic debates the "dynamic side" assumes across the board that "static OOP" == C++. This is simply not the case! > > I maintain that to use a static language with casting > amounts to paying the time-to-market cost of a static > language In other words, less? > while writing extra code to support features > that come for free in a dynamic language. Like? An example, please? > The mistake of casting NULL to an object and attempting > to call a function on it in C++ is the same mistake as > sending a message to the Nil object in Smalltalk. Sure, but C++ != static typing. > > But at runtime only the static language is likely > to cause a core dump or GPF. In other words the > result of the error is more costly. So smalltalk will happily pass a message to the nill object, and the progrm will chug along just fine? Somehow, this seems unlikely to me. > And the compiler > can't help in either case. What if the type system is constructed so that nill cannot be passed to a function? Like in SML for instance? -- ------------------------------------------------------------------------------ David Hanley, Software Developer, NetRight technologies. My employer pays me for my opinions; nonetheless he does not share all of them E-mail address munged to defeat automailers, Delete _nospam