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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: quenton@cherniak.on.ca (Dennis Smith) Subject: Re: OO, C++, and something much better! Date: 1997/01/29 Message-ID: <5co5vg$gub$1@loki.tor.hookup.net> X-Deja-AN: 213036182 references: <32ED02EE.22E2@netright.com> <32ED2448.685A@parcplace.com> <32EE20A3.755D@netright.com> <5cm364$dc2@topdog.cs.umbc.edu> <6PnYDRs-3RB@herold.franken.de> organization: Cherniak Software newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++,comp.lang.smalltalk,comp.object Date: 1997-01-29T00:00:00+00:00 List-Id: In article <6PnYDRs-3RB@herold.franken.de>, jhd@herold.franken.de (Joachim Durchholz) wrote: >James wrote: > >> Depends - are we including C and C++ here ? In either language, I have >> static type checking, but I can use casting to defeat that type checking - >> thus, I get NONE of the benefits of static typing, and also none of the >> benefits of dynamic checks (as is done in Smalltalk). > >Well, this goes overboard. I do get advantages from static typing in C/ >C++. >There's even evidence for this - one of the worst sources of errors in C >was that routine parameters were basically untyped. The first reaction was >the introduction of lint (a tool that was designed to do those checks that >the C compiler didn't do), the second was requiring types for parameters >(with some compatibility kludges, but nobody uses old-style routines >anymore). > >These are very C-specific problems though. In C, undeclared parameters **** Not all C compilers (in fact not many) convert parameters. In fact what usually happens is you put it on the stack and the recipient picks it up as if it were what was expected. Thus it might be that an integer value is treated as a pointer, or perhaps a pointer as 4 characters, or other horrible things. Having made THAT point, let me talk a bit about type checking and its uses. 1. type checking can be useful in certain places 2. type checking can be a nuisance in other places In ST you often write code that does not care (to some extent) about the type. You might create a method "increment" to add 1 to something. You can add "1" to many things (integer, float, date, time). The problems of core-dumping, aborting or what have you, which would occur in C, or even worse, slightly wrong results, in cases where type checking SHOULD have been done, are not nearly as serious in ST. For example, using the comments above on no-type-checking for procedure parameters -- lets assume one passed an integer instead of a pointer. This would either cause an abort or a garbage value in C. In ST, it is most likely that the message you would send to the non-numeric object passed would simply not be recognized and you would get a clean, informative error. MUCH better then missing type-checking in C. My point here is that lack of type-checking in ST is no nearly as serious as lack of type-checking in C (or even C++). Having said that, there ARE some cases where it might be nice to have some "optional" type-checking in ST, recognizing that it could probably not be 100% because of the nature of ST. Having done development for 10 years in C, a few months in C++ and 2.5years in ST, I would take ST over C or C++ without any second thoughts. I would ALSO insist on type-checking in any C/C++ implementation because of the nasty consequences of NOT having it. >were cast to the (rather machine-dependent) "int" type, often with heavy >loss in information and behaviour if the programmer passed something >different in. The situation is somewhat different in Smalltalk - if an >object is passed to a point it wasn't expected to go to, it still keeps >all information and behaviour. Given the completeness of the Smalltalk >libraries, chances are that the object will still respond in a useful way >to anything that is thrown at it. > >On a more general level, I really would like to have some benefits of >static typing in Smalltalk. Static typing provides much information for >optimizers. Static typing allows me to make sure my library will not crash >if some idiot passes nonsense to them. ("Idiot" in the sense that I do >idiotic things myself, sometimes.) Static typing allows me to explicitly >specify contracts between caller and routine (this is a very Eiffelish >idea that you won't find in most OO language, but it is one the C++ >community would very much like to adopt). >I found an interesting approach in Sather. You don't have to declare >everything; the compiler assumes the most general type possible if a >variable is introduced somewhere. Such an approach could, if done well, >combine the advantages of static and dynamic typing. > >Regards, >-Joachim > ------------------------------------------------------------------------------ Dennis Smith, quenton@Cherniak.ON.CA, UUCP: ..!gts!cherniak!quenton +1 905 771 7011, FAX +1 905 771 6288 Cherniak Giblon 10 Commerce Valley Dr. E. #400, Thornhill, Ont. CANADA L3T 7N7