home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19662 < prev    next >
Encoding:
Text File  |  1993-01-21  |  1.8 KB  |  49 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!fmrco!pandrews!pandrews
  3. From: pandrews@lovat.fmrco.com (Paul Andrews)
  4. Subject: Re: MI vs. SI
  5. Message-ID: <1993Jan21.093918.3738@fmrco.uucp>
  6. Sender: news@fmrco.uucp
  7. Reply-To: pandrews@lovat.fmrco.com
  8. Organization: Fidelity Investments Ltd.
  9. References: <1993Jan20.022321.18020@borland.com>
  10. Date: Thu, 21 Jan 1993 09:39:18 GMT
  11. Lines: 36
  12.  
  13. In article 18020@borland.com, pete@borland.com (Pete Becker) writes:
  14. > In article <93019.090854IO70620@MAINE.MAINE.EDU> <IO70620@MAINE.MAINE.EDU> writes:
  15. > >The only way I can think of to enforce this is
  16. > >through the use of multiple inheritance.
  17. >     Then use multiple inheritance.  It is not a "Pandora's box", except
  18. > to those who jump into hacking code without thinking about what they are doing.
  19. > But that sort of problem isn't limited to multiple inheritance...
  20. >     -- Pete
  21. Totally agree. Why oh why oh why (:-)) do folks have such a downer on MI? YES, I
  22. suppose you can do the same stuff with SI, but thats like saying "I can get from
  23. A to B by walking, why drive?" (well kind of). The point is MI is USEFUL. As people
  24. have said before: "Use it for Mixins". There is too much design of classes that
  25. can't be re-used for various reasons (private not protected members, standard not
  26. virtual functions (esp. destructors), monolithic SI class libraries).
  27.  
  28. If you want to see the best argument yet for MI, take a look at NIH (it uses SI). The
  29. library would have been much more useful written as a set of Mixins. Programmers could
  30. then decide for themselves which parts of the Object class they wanted in their
  31. programs. (P.S. NIH was first written prior to MI).
  32.  
  33. Anyway, enough ranting for now.
  34.  
  35. (Needless to say, my opinions are my own)
  36.  
  37. - Paul
  38.  
  39.  
  40. ---
  41. ---
  42. Paul Andrews
  43.  
  44. EMail                Telephone
  45. pandrews@lovat.fmrco.com    +44-71-975-4723
  46.  
  47.