home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / object / 3306 < prev    next >
Encoding:
Internet Message Format  |  1992-08-23  |  4.2 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.92Aug23221428@aberdb.aber.ac.uk>
  6. Date: 23 Aug 92 22:14:28 GMT
  7. References: <PCG.92Aug14170701@aberdb.aber.ac.uk> <1992Aug15.124149.28538@m.cs.uiuc.edu>
  8.     <PCG.92Aug16184526@aberdb.aber.ac.uk> <77947@ut-emx.uucp>
  9. Sender: news@aber.ac.uk (USENET news service)
  10. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  11. Organization: Prifysgol Cymru, Aberystwyth
  12. Lines: 76
  13. In-Reply-To: hasan@ut-emx.uucp's message of 18 Aug 92 15: 10:50 GMT
  14. Nntp-Posting-Host: aberdb
  15.  
  16. On 18 Aug 92 15:10:50 GMT, hasan@ut-emx.uucp (David A. Hasan) said:
  17.  
  18. hasan> pcg@aber.ac.uk (Piercarlo Grandi) writes:
  19.  
  20. johnson> An abstract class is much more than just an interface
  21. johnson> specification.  It also includes part of the implementation of
  22. johnson> the class, but it has some 'holes' in it that subclasses must
  23. johnson> fill in.  It is really a reusable design for subclasses, not an
  24. johnson> interface specification.
  25.  
  26. pcg> Then, wouldn't it be better to adopt a 'reusable, orthogonal'
  27. pcg> components for building a class rather than leaving bits of a
  28. pcg> monolithic definition missing?
  29.  
  30. hasan> In particular, 1) is it the notion of an "abstract class" that
  31. hasan> bothers you or is it the use of "inheritance" in any circumstance
  32. hasan> (abstract class or not)?
  33.  
  34. It's really a bit of both. "inheritance" bothers me a lot because it is
  35. commonly understood to be the equivalent of prefixing, i.e. a
  36. hierarchical reuse mechanism that does not quite distinguish between
  37. interface and implementation reuse. It is also a linguistic device with
  38. pretences of data design semantics, hence the endless and pointless
  39. debate as to whether inheritance models 'is-a' or 'has-a' or
  40. 'behaves-as-a' or 'is-represented-the-same-as-a" or other semantic or
  41. pragmatic relationships.
  42.  
  43. Abstract classes bother me a bit because if they are just interface
  44. reuse there should be a more appropriate mechanism, and if they are
  45. there to provide partially complete assemblies of interface and
  46. implementation components then I don't see a large reason to have them.
  47.  
  48. hasan> 2) do you have alternative strategies in mind (e.g., generics)?
  49.  
  50. I'd be content enough with 'modules' probably. Really what is needed is
  51. then a classification linguistic device.
  52.  
  53. One could simply provide a list of named interface and implementation (let's
  54. for the moment ignore specifications, it's much the same) components,
  55. and assemble complete classes from it.
  56.  
  57. But maybe it would be nicer to be able to assemble together components
  58. without actually forming an instantiatable class, in order to provide:
  59.  
  60. hasan> To my eyes, the appealing aspect of "mix" of spec.  and
  61. hasan> implementation mentioned by Ralph Johnson (above) is that it
  62. hasan> allows for degrees of abstractness.
  63.  
  64. which is a quite good concern. But I am very much undecided about this.
  65.  
  66. Surely one certainly wants the facility to name not just single
  67. interface and implementation components, but also groups of them; for
  68. example an interface called 'stack' could be aseembled out of the
  69. interfaces 'pop push top' and one called queue could be assembled out of
  70. 'append remove top bottom', and one called deque by merging them.
  71.  
  72. But I am not sure that it is a good idea to allow for mixed, but
  73. incomplete, assemblies of both implementations and interfaces.
  74.  
  75. I have this feeling that classes, i.e. mixed assemblied, should be
  76. complete, in the sense of being instantiatable.
  77.  
  78. In other words that the abstraction levels should be visible in separate
  79. implementation and interface lattices, without having a lattice of
  80. classes. In other words the relatedness of two classes should be not
  81. directly specified, but indirectly, by looking the the relatedness of
  82. the interface and implementation components that have been used to
  83. assemble the one and the other.
  84.  
  85. The reason for which I have this feeling is that an algebra over classes
  86. would be redundant with respect to the interface and implementation
  87. algebras,  redundancy is often suspect.
  88. --
  89. Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
  90. Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
  91. Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
  92.