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

  1. Newsgroups: comp.lang.c++
  2. From: nikki@trmphrst.demon.co.uk (Nikki Locke)
  3. Path: sparky!uunet!pipex!demon!trmphrst.demon.co.uk!nikki
  4. Distribution: world
  5. Subject: Re: Covariant Types in Derived Classes
  6. References: <1MH5C0K@netmbx.netmbx.de>
  7. X-Mailer: cppnews $Revision: 1.10 $
  8. Organization: Trumphurst Ltd.
  9. Lines: 50
  10. Date: Mon, 27 Jul 1992 20:55:45 +0000
  11. Message-ID: <712295745snx@trmphrst.demon.co.uk>
  12. Sender: usenet@gate.demon.co.uk
  13.  
  14.  
  15. In article <1MH5C0K@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
  16.  
  17. > nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
  18. > >The report generator and the user interface tool does not _require_ RTTI. 
  19. > >The objects to be displayed/reported on should return a Collection of field 
  20. > >specifiers from a virtual function. These field specifiers can then be 
  21. > >placed on a menu for user selection and placement. The field specifier 
  22. > >will contain virtual functions to format, display, validate and set the 
  23. > >value of each field. A generic user interface object can then be 
  24. > >constructed to use these methods for displaying and/or editing the field.
  25. > Now for the key question: where does this Collection of field specifiers
  26. > come from?  Are you implying that the *user* needs to code all this?  It
  27. > should not be available to a general library class?
  28. The user (by which I take it you mean programmer) would probably code this
  29. by using predefined classes for such things as string and simple numeric
  30. fields, and deriving from these classes where the field is complicated.
  31.  
  32. > Why not allow default display using exactly the same information used by
  33. > the debugger?
  34. So, as I understand it, you want some kind of RTTI which enables you to 
  35. determine not only the type (class) of any object, but also details of 
  36. every public and private variable and implementation details within the 
  37. class. Can this really be true ? If it is, you don't want C++ :-) I must 
  38. be mis-interpreting, surely.
  39.  
  40. > The alternative is to require a programming strategy like this:
  41. >     1.  Design the class you need
  42. >     2.  Write code to print objects of this class
  43. >     3.  Write code to store objects of this class in a database
  44. >     4.  Write code to display objects of this class
  45. >     5.  Write code to input and edit objects of this class
  46. > We all agree that reliable code is our goal.  General purpose tools
  47. > which can largely automate steps 2-5 will greatly reduce the amount
  48. > of code that needs to be written for each class.
  49. Fine - but these general purpose tools should be code generators, not 
  50. sufficient RTTI to enable any hack programmer to totally subvert the type 
  51. system, encapsulation, data hiding and just about everything else that's 
  52. good about OOPL's.
  53. ---
  54. Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
  55. Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
  56. PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
  57. trmphrst.demon.co.uk is NOT connected with ANY other sites at demon.co.uk.
  58. Demon.co.uk is a dial-up subscription access point to the Internet.
  59.