home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 20077 < prev    next >
Encoding:
Text File  |  1993-01-28  |  3.6 KB  |  89 lines
  1. Path: sparky!uunet!crdgw1!rpi!uwm.edu!spool.mu.edu!agate!doc.ic.ac.uk!pipex!demon!trmphrst.demon.co.uk!nikki
  2. From: nikki@trmphrst.demon.co.uk (Nikki Locke)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: MI vs. SI
  5. Message-ID: <728017608snx@trmphrst.demon.co.uk>
  6. Date: 25 Jan 93 20:06:48 GMT
  7. References: <mg.727630597@elan.princeton.edu> <1993Jan20.022321.18020@borland.com> <1993Jan21.093918.3738@fmrco.uucp>
  8. Sender: usenet@demon.co.uk
  9. Reply-To: nikki@trmphrst.demon.co.uk
  10. Organization: Trumphurst Ltd.
  11. Lines: 75
  12. X-Mailer: cppnews $Revision: 1.31 $
  13.  
  14. In article <mg.727630597@elan.princeton.edu> mg@elan (Michael Golan) writes:
  15. > pandrews@lovat.fmrco.com (Paul Andrews) writes:
  16. > >Totally agree. Why oh why oh why (:-)) do folks have such a downer on MI? 
  17. > 
  18. > Because
  19. > 1) Most implementations are buggy. Maybe all those compiler writers are
  20. >    idiots. Maybe the idea too complex and not well understood/documented.
  21.  
  22. Fair point. Most implementations ARE buggy. Likewise implementations of 
  23. templates. This should soon pass.
  24.  
  25. > 2) MI is hard to implement, hard to understand, hard to use correctly
  26.  
  27. Presumably the buggy compilers indicate it is hard to implement. I find it
  28. easy to use, and I think I understand it.
  29.  
  30. > 3) MI can add bugs that are hard to detect
  31.  
  32. Have you any evidence for this ?
  33.  
  34. > 4) MI lead to bad design, where people make one class into 3 (inhereting
  35. >    from two smaller classes), just so that (1) and (2) could possibly be used
  36. >    independently, even when this is not likely or important
  37.  
  38. I don't think this is an important criticism - almost anything can lead to
  39. bad design if you look at it like this. Why anyone would bother to 
  40. separate out functionality that is never going to be reused ?
  41.  
  42. > 5) MI is commonly used as a hack to combine incompatible classes that 
  43. >    are badly designed to begin with. This might be nice and good in the 
  44. >    short-run, for older C++ classes designs. It is most likely bad in the 
  45. >    long run.
  46.  
  47. MI can be used for this, yes. When the classes are from a library vendor, 
  48. and cannot be changed, this is a legitimate use.
  49.  
  50. > 6) They were mostly needed before the templates-era, when classes where used
  51. >    in implementing template-concepts, e.g. when a class had to be derived
  52. >    from LIST to be on the list. Then, when you wanted to collect some
  53. >    functionality on a list, you had to use MI. You still have to do so,
  54. >    if your "LIST" is some complex class, that *combines* a collection-
  55. >    mechanism with other functionality. Most such designs are bad, and 
  56. >    using MI instead of fixing the design is a bad idea.
  57.  
  58. Maybe that's why YOU used them. Not I.
  59.  
  60. > 7) The complications to the language far out-weight the benefits, and it
  61. >    seems to have no end in sight. See dynamic_cast<Ouch>(Arr)
  62.  
  63. I disagree.
  64.  
  65. > 8) People abuse SI. I have seen many abstract classes with a field "type",
  66. >    which is set by each derived class and is checked at both levels.
  67. >    I consider this "cheating". 
  68.  
  69. So do I.
  70.  
  71. >    The escape from such bad design is with MI,
  72. >    and I don't like it. 
  73.  
  74. Is it ? How ?
  75.  
  76. > You claim that the NIH lib would be better off with MI, and that this is
  77. > "clear". I challenge you to a battle of wits (The princess's bride:-).
  78. > Show us an example! 
  79.  
  80. Have you looked at my posting <727040791snx@trmphrst.demon.co.uk> in this 
  81. group ? I gave an example of MI there, and asked for comments. Perhaps you
  82. would care to redesign it using SI, and explain why the SI design is as 
  83. good (or better) ?
  84.  
  85.  
  86. -- 
  87. Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
  88. trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
  89.