home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11240 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.9 KB
  1. Xref: sparky comp.lang.c++:11240 comp.std.c++:899
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  4. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  5. Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
  6. Message-ID: <1992Jul21.162659.25474@ucc.su.OZ.AU>
  7. Sender: news@ucc.su.OZ.AU
  8. Nntp-Posting-Host: extro.ucc.su.oz.au
  9. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  10. References: <1992Jul20.143900.23087@merlin.hgc.edu> <1992Jul20.215058.1216@cadsun.corp.mot.com>
  11. Date: Tue, 21 Jul 1992 16:26:59 GMT
  12. Lines: 57
  13.  
  14. In article <1992Jul20.215058.1216@cadsun.corp.mot.com> shang@corp.mot.com writes:
  15. >Secondly, we both  
  16. >agree that it is necessary to allow rediscovery of a type. 
  17.  
  18.     In general C++ programming I do not agree that it is
  19. necessary to recover arbitrary type information. That is because,
  20. quite simply, you CANNOT use it.
  21.  
  22. >What I disagree is  
  23. >the argument that the design of heterogeneous collection is fundamentally  
  24. >wrong, which, of cause, is not your statement.
  25.  
  26.     I think I should clarify here: I am arguing against
  27. DOWNCASTING. 
  28.  
  29.     I am not against collections of objects all derived
  30. from a common base provided you access them via the base.
  31. That is the vey point of inheritance, after all.
  32. In this case the objects are all of the same type:
  33. it is homogeneous at the level it is accessed and
  34. heterogeneous at the actual object level, but the actual
  35. object level is not accessible.
  36.  
  37.     I am not against collections of objects of completely
  38. unrelated types provided the types are drawn from a finite
  39. and statically known set. In this case there is a 'type' which
  40. is the finite union of those types, so again, the collection
  41. is really homogeneous wrt that type.
  42.  
  43.     I am not against the two above combined either.
  44.  
  45.     I am against using, in general programming,
  46. DOWNCASTING or run-time type information to defeat the type system.
  47.  
  48.     I agree that in Debuggers and other such programs
  49. these facilities are essential, indeed, you need much more
  50. than a mere safe downcast or run-time type code. In a debugger,
  51. for example, you need in effect run-time access
  52. to the complete declaration and definintion of each class in
  53. the whole program!
  54.  
  55.     C++ does NOT have facilities at present to do this.
  56. I am NOT against adding them. But I would be against using these
  57. facilities in the general programming context for which C++
  58. was intended and where such mechanism are *dangerous*.
  59.  
  60.     Clearly, for example, a debugger which allows you
  61. to modify instances of a class breaks encapsulation!
  62. It breaks almost every principle you can think of. 
  63. It is meant to: you use the debugger when a more important
  64. thing is already broken : your program :-)
  65.  
  66. -- 
  67. ;----------------------------------------------------------------------
  68.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  69.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  70. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  71.