home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11502 < prev    next >
Encoding:
Text File  |  1992-07-25  |  6.1 KB  |  155 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Covariant Types in Derived Classes
  5. Message-ID: <1992Jul24.184431.12761@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. References: <P6C5COF@netmbx.netmbx.de> <1992Jul23.205820.24559@ucc.su.OZ.AU> <VKE52M@netmbx.netmbx.de>
  10. Date: Fri, 24 Jul 1992 18:44:31 GMT
  11. Lines: 142
  12.  
  13. In article <VKE52M@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
  14. >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  15. >
  16. >So far we have seen that RTTI is very useful for debuggers, class browsers,
  17. >report generators, user interface tools, databases, communications...
  18. >in other words, for a great deal of the programming tools a C++ programmer
  19. >would like to have.
  20.  
  21.     Yes. All these require a fixed piece of code to be able to
  22. manipulate arbitary objects, right?
  23.  
  24.     If you want to add RTTI to facilitate this, I have no
  25. argument.  I might argue, however, that such systems---
  26. tools for manipulating C++ itself, introspective you called them,
  27. I called them 'meta' systems, and also for interfacing to
  28. foreign interfaces--- are a different class than garden
  29. variety programs---domestic systems. I would like to 
  30. see domestic systems protected from such power.
  31.  
  32. Lets suppose you allow domestic programs access to all type info.
  33. Then there's not much point hiding the implementation is there?
  34.  
  35. However, I think what is proposed is MUCH more limited than this.
  36. So it won't give you what you want, but it will encourage
  37. and allow bad style in domestic programs.
  38.  
  39.     Note that what YOU want for the introspective
  40. systems doesn't involve downcasting, it involves
  41. MUCH deeper penetration into the system, all such systems
  42. have to get at details that ought to be hidden in
  43. domestic systems.
  44. >
  45. >>    To make proper output *requires* programmer definition,
  46. >>when I need this I just have a virtual print in all relevant classes.
  47. >>Of course, then I have to *write* the definitions, which is a pain.
  48. >
  49. >But providing a default which may be used directly or edited with
  50. >a mouse is not a pain, and is easily provided as a general tool.
  51.  
  52.     OK.
  53. >
  54. >Let me give you an example from POET, the OODB that I know
  55. >best (because I am one of the developers).  Let's say you have
  56. >an arbitrary class declaration:
  57. >
  58. >    class ArbitraryClass {
  59. >        int foo;
  60. >    public:
  61. >        float goo;
  62. >    };
  63. >
  64. >If you just write the little word "persistent" in front of this then
  65. >our precompiler will know that it should generate run time type info:
  66. >
  67. >
  68. >    persistent class ArbitraryClass {
  69. >        int foo;
  70. >    public:
  71. >        float goo;
  72. >    };
  73. >
  74. >If an object is assigned to a database then you can store it using
  75. >the Store() method, which is provided for all persistent objects:
  76. >
  77. >    ArbitraryClass ArbitraryObject;
  78. >
  79. >    ArbitraryObject->Assign(ADatabase);
  80. >    ArbitraryObject->Store();
  81. >
  82. >I'll avoid going into more detail right now, but you see that this
  83. >is very convenient.  Without RTTI it is not possible.  We do not need
  84. >a reflective system, but we do need an introspective system.  Since
  85. >C++ is not introspective, we have built our own compiler to give us the
  86. >information which all C++ compilers generate and then throw away.
  87.  
  88.     So for this RTTI is needed. It HAS to know the
  89. implementation details! It CAN break the system, so you
  90. had better buy a good OODB like POET :-) that you trust.
  91. >
  92. >I am concerned that many C++ programs downcast without any guarantee
  93. >of type safety.  Start reading large C++ programs and you will see that
  94. >downcasts are quite common.  Is the C++ community worse off if we provide
  95. >a safer way to do this?
  96.  
  97.     In domestic programs it would best to bad downcasts :-)
  98. They not necessary. And the're not possible for virtual bases,
  99. so I make all my bases virtual to make absolutely sure you
  100. cant break the type system. I dont want you to be able to do
  101. it safely---I dont want you to be able to do it at all!
  102.  
  103. For the same reason I dont want to to access the private variables.
  104. Saying 'but you need to do that for a debugger, an OODB etc'
  105. is saying something true: but that doesnt mean I want you to be
  106. able to do it domestically. The same argument could be used
  107. to say 'lets get rid of private and make everything public'
  108.  
  109. I dont want this domestically,
  110. and downcasting is precisely the same issue.
  111.  
  112. >
  113. >>    The problems you want to solve (me too, and many others :-)
  114. >>are way out of te scope of a traditional language which
  115. >>works only with memory resources. THAT is the problem, really.
  116. >
  117. >Naw.  The problems *I* am discussing have  already been solved
  118. >using C++, but we are finding sneaky ways to get at run time type
  119. >information.
  120.  
  121.     Exactly. You want a dynamic system. C++ is static
  122. and somewhat typesafe because of that. You want to do something
  123. that cant be done safely in the first place.  So C++
  124. is the wrong tool, it is restricted to PREVENT the sort of program
  125. you want to write being written.
  126.  
  127.     i agree to extend its scope, provided that this can be
  128. done without prejudicing the safety of domestic systems,
  129. which are the pricipal goal (all those debuggers are not
  130. going to be used *just* to debug themselves!)
  131.  
  132.     So I'm NOT against RTTI, or what you want to do with it,
  133. I'm sure thats why Bjarne is supporting it. I want to
  134. do those sorts of things TOO.
  135.  
  136. >
  137. >>    Wouldn't you rather just say 'persistent' and have the object
  138. >>just exist in the 'persistent'  database totally automatically :-)
  139. >
  140. >    Because the user shyould have some control over which objects
  141. >    get stored, and should be able to test the store operation for
  142. >    error returns.  But you have the right idea!  And if you look
  143. >    at my sample code given above--from a commercial system that
  144. >    is now available--you see that this kind of high level access
  145. >    is possible in C++ today, given RTTI.
  146.  
  147. Sure. We agree here. Just not about the need or advisability
  148. of downcasting in domestic, statically determined programs.
  149.  
  150. -- 
  151. ;----------------------------------------------------------------------
  152.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  153.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  154. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  155.