home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / smalltal / 2842 < prev    next >
Encoding:
Text File  |  1993-01-28  |  4.2 KB  |  93 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!ukma!gatech!paladin.american.edu!auvm!GWDG.DE!JRADE1
  3. X-Mailer: ELM [version 2.3 PL0]
  4. Message-ID: <9301281622.AA22620@gwdu03.gwdg.de>
  5. Newsgroups: comp.lang.smalltalk
  6. Date:         Thu, 28 Jan 1993 17:22:10 MET
  7. Sender:       SmallTalk programming language discussion <SMALK@FINHUTC.BITNET>
  8. From:         Joerg Rade <jrade1@GWDG.DE>
  9. Subject:      Re: Voluntary method typing in ST80
  10. Comments: To: SMALK%FINHUTC.BITNET@ibm.gwdg.de
  11. In-Reply-To:  <9301161331.AA09685@gwdu03.gwdg.de>; from "Tim Posney" at Jan 16,
  12.               93 1:15 pm
  13. Lines: 78
  14.  
  15. >
  16. >
  17. > I think the whole point of type checking depends on the time at which it
  18. > is performed. In c++ type checking is performed at compile time and is
  19.  required
  20. > since application behaviour when calling with incorrect arguments is
  21. > undefined. Not to mention that the number and type of arguments defines
  22. > which funtion (method) is called. The language and run time environment
  23. > has no mechanism for <Object does not understand>. In fact this cannot
  24. > occur (unless you do some dodgy casting - but what you get then is a nasty
  25. > run time error).
  26. >
  27. > Smalltalk on the other hand does not require (or support in its default
  28. > implementation) type checking. It is up to the application code to check
  29. > the type of arguments.
  30.  
  31. Good point.
  32. >
  33. > I am curious (see previous posting) about the implementaiton of type checking:
  34. >         1. What if you want to define the same method name, say
  35. >                 process: anObject
  36. >         and
  37. >                 process: anInteger
  38. >         If the type of the argument is used to do checking (presumably at
  39. >         compile time) did you allow overriding of methods ?
  40.  
  41. Checking is at runtime. Checking at (byte)compile time would at least for
  42. arguments that are passed unchanged from other methods result in pretty
  43. long chains (c.f. the discussion on copying objects).
  44. Do you mean overrinding of parent methods by child methods? Then the answer
  45. is yes.
  46. >
  47. >         2. If a super-class implements
  48. >                 process: anOrderedColleciton,
  49. >         the child class implements
  50. >                 process: anInteger
  51. >         and I call
  52. >                 child process: (OrderedCollection new)
  53. >         what happens, it seems to me that this should allow the super class
  54. >         method to be called.
  55.  
  56. In the code I posted, the super class method would not be called. I think it
  57. could be done in dialecs, where the Compiler classes are accessible. But
  58. wouldn't this contradict the principle of inheritance?
  59. >
  60. > If the answer to both questions is no, then I wonder about the use of the type
  61. > checking. Sure you would pick up some errors earlier, but not by much. (since
  62. > the method that used the paramaters would fall over pretty quickly too).
  63.  
  64. I do (partly) agree. I have come across some methods where I named the
  65. argument anInteger, but it was actually aSmallInteger. Although one may
  66. argue that there is nothing wrong with this (and the code could easyly be
  67. extended to handle it), my naming was less precise than it could have
  68. been.
  69. The idea of mechanisms that shape my behavior as a programmer towards
  70. precission strikes me (maybe I need more guidance than other people).
  71. The point I try to make is less on type-cheking, but more on conventions
  72. concerning the naming of arguments: one of the possible sideeffects
  73. would be to have a view on Smalltalk's classes and methods from another
  74. perspective in addition to #sendersOf:/#implementorsOf: and #globalUsers:
  75. (instantiations like: temp := Object new). Although I expect the runtime
  76. for a method that groups methods based on argument types to be long enough
  77. for a coffee break, it could offer another view on class collaboration.
  78. >
  79. > The value of type checking (IMHO) is to ensure that certain classes of errors
  80. > cannot occur. We have a large smalltalk system that has been in production for
  81. > several years now, and it is not rare to see Object does not understand errors
  82. > simply becuase the wrong type of argument has been passed. However I would
  83. > not take on strong typing eagerly since it would destroy much of the
  84. > prototyping
  85. > value that you get in smalltalk.
  86.  
  87. Right. One can allways reimplement #error: , redirect (some of) the output
  88. into a log file and answer nil.
  89. >
  90. > regards tim
  91.  
  92. TNX for your feedback - j|g
  93.