home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / object / 3305 < prev    next >
Encoding:
Internet Message Format  |  1992-08-23  |  4.0 KB
  1. Path: sparky!uunet!mcsun!uknet!gdt!aber!aberfa!pcg
  2. From: pcg@aber.ac.uk (Piercarlo Grandi)
  3. Newsgroups: comp.object
  4. Subject: Re: O.M() versus M(O) notation
  5. Message-ID: <PCG.92Aug23215341@aberdb.aber.ac.uk>
  6. Date: 23 Aug 92 21:53:41 GMT
  7. References: <1992Aug5.162329.22871@ucunix.san.uc.edu>
  8.     <PCG.92Aug12205741@aberdb.aber.ac.uk>     <__5mtrq.objsys@netcom.com>
  9.     <PCG.92Aug14170701@aberdb.aber.ac.uk>
  10.     <1992Aug15.124149.28538@m.cs.uiuc.edu>
  11.     <PCG.92Aug16184526@aberdb.aber.ac.uk>     <1992Aug16.212818.29943@m.
  12. Sender: news@aber.ac.uk (USENET news service)
  13. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  14. Organization: Prifysgol Cymru, Aberystwyth
  15. Lines: 68
  16. In-Reply-To: johnson@m.cs.uiuc.edu's message of 21 Aug 92 02: 55:30 GMT
  17. Nntp-Posting-Host: aberdb
  18.  
  19. On 21 Aug 92 02:55:30 GMT, johnson@m.cs.uiuc.edu (Ralph Johnson) said:
  20.  
  21. johnson> pcg@aber.ac.uk (Piercarlo Grandi) writes:
  22.  
  23. pcg> So, here you seem to be saying that abstract classes in most OO
  24. pcg> languages are a considerable mess, because they *ought* to be used
  25. pcg> as a poor man's template facility, and then end up being used as a
  26. pcg> poor man's interface definition facility too.
  27.  
  28. johnson> No, that is not what I am saying.  They are a good template
  29. johnson> facility.  They are all the template facility that Smalltalk
  30. johnson> needs.  C++ needs "templates" in addition to abstract classes,
  31. johnson> so they are perhaps not as good for languages with static type
  32. johnson> checking.
  33.  
  34. Actually I reckon that both the Smalltalk way and the C++ way of doing
  35. polymorphism (procedure implementations that can be applied to values of
  36. multiple 'types', as long as these 'types' have some interface in
  37. common) are fairly poor.
  38.  
  39. C++'s is bad because it is an ad hoc, static mechanism, that is really a
  40. veil for macro processing. Smalltalk's because it does not make obvious
  41. what is the interface that a polymorphic implementation requires, except
  42. by inspecting the body of the implementation.
  43.  
  44. johnson> Lots of people, including me, have argued for a long time that
  45. johnson> interface defining and class assembling should be separate
  46. johnson> facilities.
  47.  
  48. Wonderful, but:
  49.  
  50. johnson> I call the relationship between interfaces subtyping, and the
  51. johnson> relationship between classes subclassing.
  52.  
  53. More aggravating notation/terminology! Interfaces are parts of classes,
  54. unless you mean that sublassing is really only about the implementation.
  55. Or else it's hard to express the notion that implementations only are
  56. being reused.
  57.  
  58. And, more importantly, WHY, why use 'SUBclassing SUBtyping' to indicate
  59. relationships that can have nothing of subsetting, but actually be
  60. supersetting or mixed? Even 'derivation' has an excessively hierarchical
  61. connotation. I'd rather use 'interface reuse' and 'implementation
  62. reuse', separately, and maybe reserve 'class reuse' to indicate that
  63. both are meant at the same time, just as a 'class' should be built by
  64. assembling interface and implementation (and specification) components.
  65.  
  66. johnson> You are not going to get rid of inheritance, you are just going
  67. johnson> to call it by a different name.
  68.  
  69. Ah, yes, I'd call it 'hierarchical combined interface and implementation
  70. reuse'. The big problem is that the notion of 'independent reuse of
  71. interface, implementation, specification components' cannot be called
  72. 'inheritance', because it is more general. What about, an idea of the
  73. moment, calling it simply 'reuse'?
  74.  
  75. johnson> Abstract classes are more powerful than templates because you
  76. johnson> can do more than just fill in the missing operations, you can
  77. johnson> also redefine the operations that are provided.
  78.  
  79. You are probably thinking of C++ and Ada here, and I agree. But if one
  80. has general algebras over interface and implementation components,
  81. 'templates' (uninstantiatable assemblies of components) become more
  82. general than abstract classes, as *everything* can be redefined.
  83. --
  84. Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
  85. Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
  86. Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
  87.