home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 20039 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.0 KB  |  54 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!ascent!ascent!eb
  3. From: eb@ascent.com (Ed Barton)
  4. Subject: Re: Inheriting from cooperating classes (was: HELP : Array of objects...)
  5. In-reply-to: rowley@base.cs.ucla.edu's message of 27 Jan 93 20:13:30 GMT
  6. Message-ID: <EB.93Jan28101151@MountRushmore.ascent.com>
  7. Date: 28 Jan 93 10:11:51
  8. References: <rowley.728165610@base.cs.ucla.edu>
  9. Organization: Ascent Technology, Inc., Cambridge Massachusetts
  10. Lines: 42
  11.  
  12. In article <rowley.728165610@base.cs.ucla.edu> rowley@base.cs.ucla.edu (Michael T Rowley) writes:
  13.    ...
  14.    Problem: other classes in the library (e.g. LIST) create instances of
  15.    LIST_ELEMENT.  They won't use your new derived class!
  16.  
  17.    I believe this is a problem with any class that has instances created
  18.    by other library classes.
  19.    ...
  20.    I can think of two mechanism which could solve this problem:
  21.  
  22. [When you are designing a library,]
  23.  
  24.    1) Never use another class from within a class.  Use only constrained
  25.    generic parameters (parameterized types).  Thus a generic list class
  26.    would need to be declared LIST[LIST_ELEMENT,MEMBER_TYPE], or, if you
  27.    made a subclass LIST[NEW_LIST_ELEMENT,MEMBER_TYPE].  It's a little
  28.    less ugly if generic parameters could have defaults, as in Sather 1.0.
  29.  
  30.    Any other ideas?
  31.  
  32. IMO, this is an unnecessarily strong constraint.  For the cases where
  33. the new auxiliary objects are dynamically allocated by the library, I
  34. would suggest instead that the class (LIST, here) should have a
  35. virtual function that it uses to create the auxiliary objects, instead
  36. of using "new" directly.  That way, a subclass of LIST can use a
  37. subtype of LIST_ELEMENT objects if that's what is needed.
  38.  
  39. (Of course, not every class, and not every auxiliary class, is
  40. designed for inheritance.  The library designer has to think ahead and
  41. decide whether or not to support inheritance.  This discussion is
  42. therefore confined to the cases where the possibility of subclassing
  43. is supported.  It's a design flaw if subclassing is excluded without
  44. good reason, of course.)
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.