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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: traymond@craftedsmalltalk.com Subject: Re: OO, C++, and something much better! Date: 1997/01/28 Message-ID: #1/1 X-Deja-AN: 212760562 sender: traymond@craftedsmalltalk.com references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> <32E4FC5B.242C@watson.ibm.com> <32E6862D.608B@parcplace.com> <32E788D4.4B91@watson.ibm.com> <32ED2930.3B92@watson.ibm.com> organization: Crafted Smalltalk reply-to: traymond@craftedsmalltalk.com (Terry Raymond) newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-28T00:00:00+00:00 List-Id: In <32ED2930.3B92@watson.ibm.com>, "Norman H. Cohen" writes: >traymond@craftedsmalltalk.com wrote: >I presume you are using the word "procedural" to mean "not object >oriented". However, there is nothing in the example above that suggests >this. Perhaps it is the presence of a built-in array type that looks >unSmalltalk-like to you. Fine, replace the two integer types with two >classes called producerID and consumerID, make Producers an object >belonging to some collection class with an extract method that takes a >producerID object, and make Consumers an object belonging to some >collection class with an extract method that takes a consumerID object. >My argument remains the same: It is easy to inadvertently send an >extract message with a producerID argument to Consumers or an extract >message with a consumerID argument to Producers. The incorrect call >might occur only on some obscure path that testing fails to exercise. >Strong typing allows such errors to be caught at compile time. Agreed, it does. But, it costs more to do so. One reason there is a lower incidence of type errors in smalltalk programs is that it uses named parameters. I know that ADA has named parameters but last time I looked they were not required. Named parameters are required in smalltalk for anything other than unary messages and binary operators. The point that most of the smalltalk programmers are trying to make here, is not that strong typing will not do a better job of catching type errors earlier than one would in smalltalk, but that because of other features in smalltalk the incidence of type errors is much lower and the additional benefit of strong typing would not be worth the reduction in flexibility. Furthermore, many of us realize that smalltalk would benefit by having type-inference tools to advise us of potential errors. But, we would use these as lint-like analysis tools. One point that I don't think has been brought out well enough is that smalltalk is incrementally compiled. So, whenever I compose a method it is compiled. Frequently, the state of my instance variables description is incomplete and sometimes my method description is incomplete but I can still compile the method. Strong typing makes it very difficult to do this. Instead, I would have to resort to using a file based editor and then do the compilation after my description was sufficiently complete. I should also add the value of having an incomplete description in the environment is that I can use the smalltalk browser and cross-referencing tools to remind me what I have called things and what I am doing with them. If I use a file editor for this I have scroll up and down, search back and forth, use grep to find something in a different file, and etc... Again, it is not that we think strong typing has no benefit, but we think that with smalltalk and its environment the benefit of enforced strong typing is not worth the cost. =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk *Breakpoints* and *Watchpoints* for 19 Tilley Ave. VW and ENVY/Developer Newport, RI 02840 (401) 846-6573 traymond@craftedsmalltalk.com http://www.craftedsmalltalk.com ===========================================================