home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11437 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  5.8 KB

  1. Xref: sparky comp.lang.c++:11437 comp.std.c++:929
  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: Language extensions for run-time type identification
  6. Message-ID: <1992Jul23.174158.13819@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: <TMB.92Jul20182052@arolla.idiap.ch> <1992Jul20.220534.1365@cadsun.corp.mot.com> <1992Jul21.094204.20100@mole-end>
  11. Date: Thu, 23 Jul 1992 17:41:58 GMT
  12. Lines: 121
  13.  
  14. In article <1992Jul21.094204.20100@mole-end> mat@mole-end writes:
  15. >In article <1992Jul20.220534.1365@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
  16. >
  17. >> I sencond this. As I already said, run time type checking of classes
  18. >> only with virtual functions is not a serious solution.
  19. >> David Shang
  20. >
  21. >Let's be sure that we are talking about the same thing, then I'll ask you
  22. >to refute an assumption underlying the current proposal.
  23. >
  24. >The current proposal would allow a number of things, including at least
  25. >checked downcasting and some kind of comparison-for-equality of the exact
  26. >type of objects.
  27. >
  28. >There are many bad uses for these facilities, but there are also good
  29. >uses, or so it is believed.
  30. >
  31. >The assumption underlying the decision to include only classes with
  32. >virtual functions is that a class that has no polymorphic behavior
  33. >whatsoever (not even a virtual destructor) cannot be used in any way
  34. >that is both safe and interesting even with the proposed runtime type
  35. >support.  Can you refute this assumption?
  36. >-- 
  37.     Before I start: I'm not against adding RTTI. But allow
  38. me to play 'devils advocate' as hard as I can. :-) Convince
  39. me that downcasting is a good thing, for example.
  40.  
  41.     What is the basis for this assumption?
  42.  
  43.     On the contrary, polymorphism BY NATURE, provides the 
  44. correct mechanism for accessing the exact object, it is 
  45. especially in this case that casting is not only dangerous
  46. but unnecessary.
  47.  
  48.     In the discussion about RTTI I have participated in with David,
  49. we agree on at least one thing: RTTI is required for writing Debugger.
  50. Clearly a debugger needs access to ALL the type information,
  51. so mere safe downcasting and comparison for equality would not be
  52. adequate, nor a restriction to classes with virtual functions.
  53.  
  54.     I think precisly the same argument applies to, say,
  55. an OO database or any other facility for porting/storing, or
  56. accessing objects. Here enough information is required
  57. to construct objects in the media/user interface.
  58.  
  59.     Using a classification scheme suggested by David, I will
  60. call the systems requiring external access *foreign* systems,
  61. and the debugger is what I might call a *meta* system.
  62.  
  63.     In any case the RTTI proposal above will not adequately
  64. support these types of systems, although it might aid in their design.
  65.  
  66.     That leaves what might be called *domestic* systems,
  67. your common garden program for doing matrix algebra, parsing
  68. a language, etc. These systems include the bulk of operating
  69. systems and other things too.
  70.  
  71.     It is my belief that DOWNCASTING in such domestic systems
  72. is never necessary. In such systems your program creates
  73. all the objects, therefore, at the point the object is created
  74. it knows the exact type of the objects.
  75.  
  76.     It is always possible, I contend, to preserve that type
  77. information if it will be required later. If it is thrown away,
  78. the information is deliberately lost specifically to prevent
  79. the object from being accessed with knowledge of its type.
  80.  
  81.     For example, if I have an abstract class A, and
  82. a subroutine returns a pointer to A, then the subroutine
  83. is deliberately coded so that the true type of the object
  84. cannot be known. That gives me freedom to change the implementation,
  85. knowing for sure nothing can depend on the actual type of the object.
  86. Everthing depends only on the interface specified in the abstract class.
  87.  
  88.     If that pointer can be cast, whether safely or not,
  89. whether by RTTI or not, to a derived type, then the
  90. implied encapsulation of the OPEN/CLOSED principle is destroyed.
  91. That is, not only is the private implementation of a base class
  92. hidden, but also all the details of all derived types are hidden,
  93. and for the same reason: they are allowed to be changed.
  94.  
  95.     In the case of downcasting it is much more serious than
  96. accessing implementation details: this does not require
  97. change of the private section, but merely the existence
  98. of several derived classes.
  99.  
  100.     The correct way to view RTTI then, is not to 
  101. support downcasting, but ANY casting, including and
  102. especially casting from a void* to any class at all.
  103.  
  104.     As such, there is no reason that I can see that
  105. such casts would be 'interesting' only when there is
  106. by chance a base with a virtual function, since
  107. in that case casting (downcasting) is especially bad style.
  108.  
  109.     [Never-the-less, if we're going to downcast,
  110. it should be at least *possible* for virtual bases.]
  111.  
  112.     There is probably a similar argument for
  113. comparison for equality, or, better, comparison
  114. to see if one class is heir to another, however in this
  115. case the use of RTTI might be more essential,
  116. since it facilitates binary operators acting
  117. on two objects of the same type, a poor mans
  118. version of multi-methods or safe covariant
  119. parameters.
  120.  
  121.     In summary: the proposal above does not go
  122. far enough to support those genuine uses of RTTI in foreign
  123. or meta systems, and attempts to support casting in domestic
  124. systems where it is not only not required, but actually
  125. invalidates the rationale of class based programming,
  126. namely the open/closed principle.
  127.  
  128.  
  129. -- 
  130. ;----------------------------------------------------------------------
  131.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  132.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  133. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  134.