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.3 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 108717,c1d77749223627c8 X-Google-Thread: 1108a1,8802fe2212b159e1 X-Google-Thread: 114809,8802fe2212b159e1 X-Google-Thread: 103376,6cd90863b65ff36b,start X-Google-Attributes: gid108717,gid1108a1,gid114809,gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread2.news.pas.earthlink.net.POSTED!01cc3b7c!not-for-mail Reply-To: "Richard Riehle" From: "Richard Riehle" Newsgroups: comp.programming,comp.object,comp.lang.smalltalk,comp.lang.ada References: <40f3ceee@alpha.wvnet.edu> <19iip59qsl122$.3g3hicltra17.dlg@40tude.net> <40f5bbe1@alpha.wvnet.edu> <40f67c13@alpha.wvnet.edu> <9qTRc.61502$M95.25853@pd7tw1no> <411C5D2F.5070408@acm.org> <3bOUc.46253$US4.14922@trndny01> Subject: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: Date: Thu, 19 Aug 2004 00:37:08 GMT NNTP-Posting-Host: 66.81.217.143 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.news.pas.earthlink.net 1092875828 66.81.217.143 (Wed, 18 Aug 2004 17:37:08 PDT) NNTP-Posting-Date: Wed, 18 Aug 2004 17:37:08 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: g2news1.google.com comp.programming:8401 comp.object:5789 comp.lang.smalltalk:2534 comp.lang.ada:2826 Date: 2004-08-19T00:37:08+00:00 List-Id: "Thomas G. Marshall" wrote in message news:3bOUc.46253$US4.14922@trndny01... > Richard Riehle coughed up the following: > > Please give us an example of a type definition that > > is difficult to catch and fix. > > > > Richard Riehle > > I don't understand what you're asking him. Are you saying that you've never > seen a complicated model with a set of types that was ever so slightly /off/ > the mark so that it was difficult to discover, and also laborious to fix? > There are several parts to your question. 1) Complicated model 2) Incorrect types ("ever so slightly /off/ the mark 3) Difficult to discover 4) Laborious to fix My experienc iis primarily with Ada, so these questions are not quite as relevant as they might be in some other language. Nevertheless, I will answer them. I have seen designs where the there were too many types defined. In particular, people sometimes design too many floating point types. For example, package Real_Numbers is type Real is digits 8 range -2000.0 .. 2000.0; type Degree is digits 6 range 0.0 .. 360.0; -- and many more such definitions end Real_Numbers; In the above example, it might be more useful to derived Degree from Real, or create an Ada subtype (I will not define the difference here, but it is different) from Real for Degree. When there are too many variations on floating point, one often has to do too much type conversion elsewhere within the program. However, Ada never lets you get this wrong. As to incorrect types, this will most often occur in composite types, especially record types. On might forget to include a component of the type in the definition. Since record types, in Ada, are most frequently defined as "limited" types, they are not part of the public part of a specification. This makes it quite easy to correct them without disturbing the integrity of the underlying specification. As to being difficult to discover, I have not seen this very often in programming with Ada. The language is designed so the compiler will quickly highlight any inconsistencies. The compilation process is not based on textual information alone. Each unit that depends on another unit requires the unit on which it depends is successfully compiled first. The compiler will not even begin to compile a unit unless its dependency relationships have been resolved. This lends itself to rapid discovery of problems with type definitions. When we consider laborious to fix, I rarely find that to be a problem. In fact, I cannot think of the last time (in nearly 20 years) where the problem with a type was laborious to fix. Certainly, when I was a novice there were problems I could not easily resolve. With experience, I have found that well-designed Ada does not entertain me with the kind of mysterious errors I sometimes encounter in other languages. I realize that most readers do not benefit fromt the Ada static compilation model. Still, that model does have the appeal, to those who do enjoy it, of making the type system a blessing rather than a nuisance. Now. I would still like to see some examples of type problems that correspond to the four points in your reply, above. Richard Riehle