home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19926 < prev    next >
Encoding:
Text File  |  1993-01-27  |  3.0 KB  |  71 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!hela.iti.org!usc!ucla-cs!rowley
  3. From: rowley@base.cs.ucla.edu (Michael T Rowley)
  4. Subject: Inheriting from cooperating classes (was: HELP : Array of objects...)
  5. Message-ID: <rowley.728165610@base.cs.ucla.edu>
  6. Sender: usenet@cs.ucla.edu (Mr Usenet)
  7. Nntp-Posting-Host: bath.cs.ucla.edu
  8. Organization: UCLA, Computer Science Department
  9. Date: 27 Jan 93 20:13:30 GMT
  10. Lines: 59
  11.  
  12. The discussion of mixed lists brought to mind an issue that I have
  13. recently been struggling with.
  14.  
  15. nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
  16.  
  17. >In article <mcampbel.727881449@eola.cs.ucf.edu> mcampbel@cs.ucf.edu (Mike Campbell ) writes:
  18. >> 
  19. >> I agree with your analysis of the problem re: subclasses, however, what if
  20. >> you buy/purchase/steal classes from multiple vendors/coworkers/victims ?
  21. >> They necessarily will not have a common base class.  (Or is this correctly
  22. >> deemed "superclass?")
  23.  
  24. >So miltiply derive from the vendors class and from a common base class of 
  25. >your own.
  26.  
  27. This works fine unless you have cooperating classes.  I came across
  28. this problem in some parsing classes, but a more familiar example
  29. would be a LIST class, which uses a LIST_ELEMENT class.  Assume these
  30. classes are distributed without source, and that, for some reason, you
  31. want to modify the LIST_ELEMENT class.
  32.  
  33. OO marketing says that if you want to create a class that is just an
  34. extension of an existing library class, all you have to do is inherit
  35. from it and make your extensions in the derived (child, sub) class.
  36.  
  37. Problem: other classes in the library (e.g. LIST) create instances of
  38. LIST_ELEMENT.  They won't use your new derived class!
  39.  
  40. I believe this is a problem with any class that has instances created
  41. by other library classes.
  42.  
  43. In the system I was working on, I had source to the library classes,
  44. so I changed the class name of LIST_ELEMENT to LIBRARY_CLASS_ELEMENT,
  45. then made a new class called LIST_ELEMENT which inherited from the
  46. original version.  This way my modified class was used by the other
  47. library classes.
  48.  
  49. If I didn't have the source, what could I have done?
  50.  
  51. I can think of two mechanism which could solve this problem:
  52.  
  53. 1) Never use another class from within a class.  Use only constrained
  54. generic parameters (parameterized types).  Thus a generic list class
  55. would need to be declared LIST[LIST_ELEMENT,MEMBER_TYPE], or, if you
  56. made a subclass LIST[NEW_LIST_ELEMENT,MEMBER_TYPE].  It's a little
  57. less ugly if generic parameters could have defaults, as in Sather 1.0.
  58.  
  59. 2) Allow for the creation of new _parent_ classes for existing
  60. classes.  The new parent would include an explicit listing of children
  61. (the children then don't have to declare the parent).  Thus the
  62. extensions get inserted into the desired class.  Any member functions
  63. that the new parent needs to use from its child can be declared as
  64. deferred functions.  Unfortunately, this does not allow for redefining
  65. functions from the library class, only adding new functions.
  66.  
  67. Any other ideas?
  68.  
  69. Michael Rowley
  70. rowley@cs.ucla.edu
  71.