home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11369 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  3.4 KB
  1. Path: sparky!uunet!mcsun!fuug!demos!kiae!glas!demos!cadsun.co!corp.mot.com!shang
  2. From: shang@corp.mot.com
  3. Newsgroups: comp.lang.c++
  4. Date: 17 Jul 92 18:02 MDT
  5. Subject: Re: run-time type checking (was: Re: Co
  6. Sender: Notesfile to Usenet Gateway <notes@glas.apc.org>
  7. Message-ID: <1992Jul17.140200.15575@cadsun.co>
  8. References: <BrG239.7oA@apollo.hp.com>
  9. Nf-ID: #R:BrG239.7oA@apollo.hp.com:-396143030:1992Jul17.140200.15575@cadsun.co:-1066702630:001:3004
  10. Nf-From: corp.mot.com!shang    Jul 17 18:02:00 1992
  11. Lines: 64
  12.  
  13.  
  14. In article <TMB.92Jul16223822@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M.  
  15. Breuel) writes:
  16. > 
  17. > Frankly, I don't see why the language should make more effort to have
  18. > built-in support for dynamic typing (a feature that most people use
  19. > relatively rarely) before it has built-in support for arrays (meaning,
  20. > array bounds checking and multidimensional arrays).
  21. >
  22.  
  23. The language should provide run time type checking as well as array bounds  
  24. checking. You can also have a switch to turn off them if you like to.
  25.   
  26. >    > The language cannot prevent "accidents"
  27. >    > while still allowing valid uses.
  28. > 
  29. >    The current C++ can't.
  30. > 
  31. > Actually, no language that uses dynamic typing (as you suggest) to
  32. > implement heterogeneous collections can "prevent 'accidents' while
  33. > still allowing valid uses".  It is in the nature of dynamic typing
  34. > that runtime type errors can occur (although they need not lead to the
  35. > catastrophic consequences they leed to in C++).
  36. >
  37.  
  38. The run time type checking that I suggested is different from those applied in  
  39. dynamic typing languages where a type error is caught at run time. My proposal  
  40. is specially made for strongly typed language (any type error should be caught  
  41. at compile time ). There is no automatic run time type check. Programmers are  
  42. responsible to write the run time type check code when they try to do something  
  43. which usually violates the conventional static type system, for example, they  
  44. try to use type downcast. The explicit run time type check will enssure that  
  45. run time type error will NEVER happen, while this can be checked at compile  
  46. time through type inference.
  47.  
  48. > SML in my opinion solves the problem more satisfactorily than either
  49. > Lisp or C++: it forces you to make sure that you have at least thought
  50. > about all the different cases of types that may occur when you build
  51. > heterogeneous collections. It does this by requiring you to declare
  52. > tagged union types for the objects that can occur in a heterogeneous
  53. > collection, and by warning you if not all the possible type cases of a
  54. > union type are handled.
  55. > 
  56.  
  57. This is also incorporated in my proposal, though I did not memtioned. Take an  
  58. example of class Number and its operator+, x+y may return an object of either  
  59. type of x (thisclass) or type of y. Therefore, the operator+ should be defined  
  60. as <Number InputType> Number{thisclass,InputType} operator+(InputType y); The  
  61. output type is a union type tagged with Number and a list of possible type  
  62. cases, i.e. Number{thisclass,InputType}. 
  63.  
  64. > This is not quite as general as what Lisp provides, but the
  65. > differences are only important when new datatypes can be created after
  66. > the program has been started (which is not a problem in C++, since C++
  67. > development is non-incremental). Furthermore, providing Lisp-style
  68. > dynamic typing breaks encapsulation and abstraction, which you may or
  69. > may not care about.
  70. >
  71.  
  72. I never advocate Lisp-style dynamic typing for strongly typed languages.
  73.  
  74. David.
  75.  
  76.  
  77.