home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / object / 4686 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  7.0 KB

  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!gdt!aber!fronta.aber.ac.uk!pcg
  2. From: pcg@aber.ac.uk (Piercarlo Grandi)
  3. Newsgroups: comp.object
  4. Subject: Re: A Pre-Release FAQ
  5. Message-ID: <PCG.93Jan1185311@decb.aber.ac.uk>
  6. Date: 1 Jan 93 18:53:11 GMT
  7. References: <1992Dec29.042355.10967@netcom.com> <PCG.92Dec29203617@decb.aber.ac.uk>
  8.     <37B01UW@minnie.zdv.uni-mainz.de>
  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: 147
  13. In-Reply-To: beckmann@Informatik.Mathematik.Uni-Mainz.DE's message of 31 Dec 92 10: 49:41 GMT
  14. Nntp-Posting-Host: decb.aber.ac.uk
  15.  
  16.  
  17. On 31 Dec 92 10:49:41 GMT, beckmann@Informatik.Mathematik.Uni-Mainz.DE
  18. (Markus Beckmann) said:
  19.  
  20. beckmann> In article <PCG.92Dec29203617@decb.aber.ac.uk>, pcg@aber.ac.uk
  21. beckmann> (Piercarlo Grandi) writes:
  22.  
  23. pcg> A point of order too: a FAQ should not be about the FAQ author's
  24. pcg> opinions; the FAQ should only be a list of facts...
  25.  
  26. pcg> Are you so incredibly sure that the type of an object and its class
  27. pcg> are the one and same concept, such that 'type' and 'class' are just
  28. pcg> synonyms?
  29.  
  30. beckmann> A list of facts:
  31.  
  32. The fact is that several authors make that mistake, and some don't
  33. (IMNHO).  I'd like to comment with my well founded (;->) arguments about
  34. it, because it's a subject that is important in its own right, not
  35. because of the FAQ, and it gets rehashed eveyr now and then, and I have
  36. a missionary streak.
  37.  
  38. [Warning: I have trimmed down the quotations to those parts I thought
  39. more significative for the points I make]
  40.  
  41. beckmann> Booch ('OOD with applications', p.59) "The concept of a type
  42. beckmann> derives primarily from the theories of abstract data types.
  43.  
  44. OK so far. The firm grounding of the notion of type is in algebraic
  45. theory.
  46.  
  47. beckmann> ... For our purposes, we will use the terms type and class
  48. beckmann> interchangeably.(/footnote A type and a class are not exactly
  49. beckmann> the same thing; [ ... ] For most mortals, however, separating
  50. beckmann> the concepts of type and class is utterly confusing and adds
  51. beckmann> very little value. It is sufficient to say that a class
  52. beckmann> implements a type.)
  53.  
  54. Here I disagree vehemently with Booch. The result of his attitude ("I
  55. know that the difference is important, but you cannot grasp it") is that
  56. people like Hathaway get utterly confused terminology (I have the
  57. suspicion that he "feels" the difference, he just has been exposed to
  58. too many Booch like verbiage to express itt naturally).
  59.  
  60. beckmann> ... and an other one for the mortals...
  61.  
  62. Maybe instead of patronizing the reader Booch could have tried to make
  63. the little extra effort and avoid confusing an abstract entity and its
  64. implementation, a fairly gross and grave thing. It is a bit like
  65. confusing a numeral and a number, or a picture of something and the
  66. something. "Ceci n'est pa un pipe", as Magritte, a *painter* remarked.
  67. Are computer scientists to be presumed unable to make the same
  68. distinction?
  69.  
  70. beckmann> B. Meyer ('OO Software Construction',p.61) "Level 4 (Classes):
  71. beckmann> Every non-simple type is a module, and every high-level module
  72. beckmann> is a type. ...  A language construct combining the module and
  73. beckmann> type aspects is called a class."
  74.  
  75. So Type != Class.
  76.  
  77. beckmann> dto. (p.72) "There are no other objects than class instances:
  78. beckmann> any object is an instance of some class C. C is said to be the
  79. beckmann> _type_ of the object."
  80.  
  81. Here he seems to reverse himself. Either C is a module plus a type, or
  82. it is just the type. Another case of careless editing. (Cardelli and
  83. Wegner in their article I referred to speak of type, incompatibly, as
  84. either a language construct or as a set of values).
  85.  
  86. beckmann> B. Stroustrup ('What is "Object-Oriented Programming"',
  87. beckmann> article) "The declaration of class (that is, user defined
  88. beckmann> type)..."
  89.  
  90. Ah but here Stroustrup is referring to the language construct in both
  91. cases! Indeed a problem we had in the past with the FAQ author is that
  92. he did not seem quite capable of distinguishing between 'declaring a
  93. type' (a language entity) and the type of a value (an algebraic entity).
  94. Lots of people have difficulty with that too.
  95.  
  96. beckmann> S. Khoshafian ('Object Orientation', p.49) "A class
  97. beckmann> incorporates the definition of the structure as well as the
  98. beckmann> operations of the abstract data type. Thus, a class defines an
  99. beckmann> abstract data type."
  100.  
  101. Another glaring example of poor wording. The class does not *define* an
  102. abstract data type; it does *implement* one.
  103.  
  104. |>              This would be amazing news to most of the people who
  105. |>              have
  106. |>   been working on formal methods and OO systems.
  107.  
  108. beckmann> Are the above books exotic?
  109.  
  110. No, and as I read them they support my two contentions: that type is
  111. not the same as class, and that however several people make the
  112. distinction, and several don't. It also supports a new contention I can
  113. make: that several authors patronize their readers assuming that they
  114. are too dumb to understand the distinction, as "too abstract", beyond
  115. "mere mortals". I really dislike this; the distinction is not something
  116. that can be swept under the carpet. Even if programmers were "mere
  117. mortals" they ought to be told.
  118.  
  119. beckmann> I think a FAQ should not discuss 'all' the aspects of
  120. beckmann> different definitions but give an overview of what all the
  121. beckmann> posting is about.
  122.  
  123. But if the most obvious aspect of an item is controversy, it should
  124. document the controversy. Your quotations (thanks for taking the time)
  125. are an excellent example of this; even if they were meant to demonstrate
  126. that several authors write 'type is more or less the same as class",
  127. they actaully reveal a far wider spectrum of opinion, as in:
  128.  
  129.     type is not the same as class, but mere mortals cannot
  130.     understand the difference.
  131.  
  132.     a type declaration can also be called a class declaration,
  133.     at least in some *languages*.
  134.  
  135.     classes *implement* types, plus some other aspects.
  136.  
  137. and so on. If I start quoting from papers that emphasize that type is
  138. not the same as class, then we have even more diversity. To be informed
  139. at least summarily of the diversity is an important value added of a
  140. FAQ.
  141.  
  142. beckmann> Otherwise every article should have a preface like "I use
  143. beckmann> objects of Grandi-type (or class? ;-), I am talking about
  144. beckmann> Hathaway-Classes...".
  145.  
  146. Indeed such terms are so overloaded with different meanings and
  147. therefore so ambiguous that they should always be qualified; ideally
  148. there should be different words. I have been pondering this for a while;
  149. I would call type as an algebraic entity 'type', as this is an
  150. established custom in maths, and type as a language construction a
  151. 'mode'. So for example
  152.  
  153.     struct complex { float re,im; complex(...) .... ; };
  154.     complex i(0,1);
  155.  
  156. would declare a mode complex and 'i' would be a variable initially
  157. denoting a value that represents the imaginary unity of the Complex
  158. type.
  159. --
  160. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  161.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  162.   alle orecchie del suo divino protettore, il dio della barzelletta
  163.