home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / object / 3375 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  10.5 KB

  1. From: kers@hplb.hpl.hp.com (Chris Dollin)
  2. Date: Wed, 2 Sep 1992 11:15:20 GMT
  3. Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
  4. Message-ID: <KERS.92Sep2121520@cdollin.hpl.hp.com>
  5. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  6. Path: sparky!uunet!sun-barr!ames!elroy.jpl.nasa.gov!sdd.hp.com!scd.hp.com!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
  7. Newsgroups: comp.object
  8. References: <1992Aug5.162329.22871@ucunix.san.uc.edu> <KERS.92Aug26181137@cdollin.hpl.hp.com> <#6jn_y+.objsys@netcom.com>
  9. Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
  10. Lines: 214
  11. In-Reply-To: objsys@netcom.com's message of 1 Sep 92 22:51:39 GMT
  12. Nntp-Posting-Host: cdollin.hpl.hp.com
  13.  
  14.  
  15. In article ... objsys@netcom.com (Bob Hathaway) writes:
  16.  
  17. | [I think we've beaten these subjects to death and I unfortunately don't have
  18. | the time for these long replies.  I'll just wrap-up and let us try to get
  19. | on with things.  Perhaps a wrap-up from Chris would be nice too]
  20.  
  21. I agree about the amount of time we're taking. I'll try to be brief and
  22. not *too* argumentative in this posting -- it's only just over 200
  23. lines long.
  24.  
  25. I'll attempt to summarise positions rather than giving a blow-by-blow
  26. response to Bob's wrap-up. I hope there'll be enough context around to
  27. make things clear.
  28.  
  29. -- On multi-methods ---------------------------------------------------
  30.  
  31. The term seems to have been invented by the CLOS community and it seems
  32. wise to restict its use to the CLOS style of method dispatch in order
  33. to avoid confusion.
  34.  
  35. CLOS has both ``ordinary'' functions (provided by the Common Lisp in
  36. which it is present) and ``generic functions'' (which provide, or
  37. ``are'', multi-methods). Multi-method invocation is not biassed toward
  38. any particular argument as a ``receiver'' of the ``message'', or toward
  39. any particular class as ``owning'' the method.
  40.  
  41. Bob correctly calls me on the ``symmetry'' I have been claiming for
  42. multi-method dispatch, because of the CLOS's (default!) left-to-right
  43. precedence order. Note, however, that this precedence order is used only
  44. when selecting among several applicable methods, to decide whether one
  45. method is ``more specific'' than another. When the details of Bob's
  46. dispatch algorithm are known, it will be interesting to compare them to
  47. the CLOS one.
  48.  
  49. -- On packaging & ``friend'' ------------------------------------------
  50.  
  51. Bob says that classes and friends are more powerful than packaging,
  52. because they give you more control over scoping -- that is, you
  53. can express the necessary connections of names without having to provide
  54. many additional connections.
  55.  
  56. I think that name-hiding is important *independantly* of classes,
  57. because classes are but one of the interesting structuring methods to be
  58. found in programming. If the C++ notion of ``friend'' is genuinely
  59. useful, it can be incorporated into a module mechanism -- presuming that
  60. other, more elegant, techniques are not found.
  61.  
  62. Bob regards CLOS as not having a ``real'' protection mechanism. I regard
  63. it as having a real, if less powerful than I would like, protection
  64. mechanism, viz packages. I think Bob confuses the philosophy of Lisp
  65. systems with language structures they provide -- a Lisper might be
  66. unhappy to be deprived to access to the internal symbols of a package,
  67. but the Lisp ``packages+generic functions'' approach would transplant
  68. quite happily to such an environment -- and give the protection that Bob
  69. desires.
  70.  
  71. -- On physics and modelling the world ---------------------------------
  72.  
  73. Bob's position, which initially I read as ``the world *is* made of
  74. objects which interact by sending messages'', seems now to be that as
  75. our knowledge of the world improves, so do our models [It's not clear
  76. to me if by ``model'' he means ``program''; I certainly don't.] and
  77. hence, so do our object-oriented models.
  78.  
  79. My position is that physics teaches us that objects are *not* givens of
  80. the natural world, and that the notion of ``object'' is a human
  81. construct -- very useful, true as far as it goes, but only one way of
  82. viewing an enormously rich world, and inadequate to describe in its own
  83. terms phenomena that actually arise in the world -- phenomena of
  84. *relation* rather than *object*.
  85.  
  86. And that, so far as modelling the world goes, use whatever works.
  87.  
  88. -- Bob's Book ---------------------------------------------------------
  89.  
  90. Bob suggests that he's going to produce a book explaining his views more
  91. fully.
  92.  
  93. I look forward to reading it. Have you a publisher?
  94.  
  95. -- OO Books -----------------------------------------------------------
  96.  
  97. I treat this one with quoting, because it makes a point that I think has
  98. been important at several places in this debate.
  99.  
  100. | [On all OO books (hundreds of them) oriented towards more accurately modeling
  101. | the real world.  Chris doesn't beleive me?]
  102. |
  103. | There're too many to list.  Just go to your local technical bookstore and dig
  104. | thru a few hundred.  If you do this and don't find literally hundreds of them
  105. | (maybe your bookstores stock differently than ours) send email and I'll send
  106. | you a list.  I'm not just going to send you the oggles of them lying around
  107. | on my (and others) desks.
  108.  
  109. Bob seems to have missed my point and substituted one of his own -- in
  110. wild defiance, I might add, of my message, which read:
  111.  
  112. # Well then, let's have the references. Let's say ten works which take the
  113. # view that the world is object-oriented in the style that Bob has
  114. # described in earlier posts.
  115. #
  116. # I am *not* interested in works by the sellers of OO methods or OO
  117. # language designers, unless they specifically address the issue of the
  118. # ``universality'' of OO. I *am* interested in works by physicists,
  119. # philosphers, and psychologists. If you (Bob, or any other reader) don't
  120. # like these criteria, let me know why.
  121.  
  122. I do not doubt that the sellers of OO methods are using OO to model the
  123. real world, and that they be doing a better job of such modelling than,
  124. say, ``functional modelling'' does, or hack-and-slay coding does, or
  125. Blind Faith ``Do What You Like'' does. The point we were addressing [or
  126. I thought we were addressing]
  127.  
  128.    Are the notions of OO (objects, messages, encapsulation) in some
  129.    sense a property of the *world*, or are they just was in which we
  130.    *think* about the world? Is the world ``object oriented''?
  131.  
  132. That is, we started out talking philosophy. Now Bob appear to be talking
  133. about software engineering. I don't mind, so long as it's clear what
  134. the topic *is*.
  135.  
  136. I would rather like to know which ones are *representative* of Bob's
  137. rather -- to my mind -- extreme point of view.
  138.  
  139. -- On concurrency -----------------------------------------------------
  140.  
  141. Bob has expressed surprise at my my surprise at him having concurrency
  142. in his model. In fact, I was not surprised at *having* concurrency, but
  143. at him having produced it out of a hat -- concurrency not being a
  144. standard feature of OOP.
  145.  
  146. This reduces to my not knowing what the base level of Bob's OO system
  147. being. Since Bob has never spelt it out, I do not think I am entirely at
  148. fault.
  149.  
  150. [Let it be recorded that I think that concurrency *is* an important
  151. feature of our descriptions of the real world, and a useful thing to
  152. have in a programming language. Let it also be recorded that I think it
  153. can be very tricky.]
  154.  
  155. Bob suggests that there are many excellent reference works on concurrent
  156. OO systems. I would be happy to hear what they are. [Reading them is, of
  157. course, unlikely to affect my views on how OO is related to physics and
  158. the real world, although it might teach me a great deal about certain
  159. representational schemes.]
  160.  
  161. -- On modes of discourse ----------------------------------------------
  162.  
  163. Because of my persistant failure to convince Bob of anything (and, I
  164. suppose, the reverse as well), I suspect some communicational problem.
  165. Bob suggests in several places that I am ``confused'', without seeming
  166. to realise that, to me, *he* is confused.
  167.  
  168. To improve communication, we should (have made) make our bases clear; to
  169. say what problems we are trying to solve; to avoid ascribing to others
  170. feelings and ideas not supported by their own words. I cite:
  171.  
  172. | You seem to have latched on to some trivial static efficiency tricks and
  173. | took them as the general case.
  174.  
  175. Here (as elsewhere) he seems to have invented some behavior for me which
  176. is not only false-to-fact, but pointing *away* from positions I might
  177. reasonably be thought to hold. Where in what I have said is there a
  178. suggestion of ``static efficiency tricks''? Given that I have not
  179. *argued* for static *anything*, whay should I be taken to be bound by
  180. certain ``static ... tricks''?
  181.  
  182. | Maybe you should consider this issue further before posting any more
  183. | specifically on this subject.  It appears to me you're not even close
  184. | and I'll often assume someone is when they discuss a subject.  You're Ok
  185. | on other points but seem to be still learning on this one.
  186.  
  187. Since Bob hasn't said what he thinks my confusion is (that is, in the
  188. light of my earlier remarks, he hasn't stated what the problem is), I
  189. have no idea what he means. How am I supposed to make progress?
  190.  
  191. The tone of the last sentence is condescending.
  192.  
  193. | >That's odd, because a few messages back, you claimed that they *did*
  194. | >have multi-methods. At least, that's how *I* read what you said; if you
  195. | >were actually discussing your company's own language, there was no way I
  196. | >could tell, and you certainly didn't disabuse me of the notion.
  197. |
  198. | Nope, you were confused.  You were claiming that O.M(...) meant single
  199. | argument dispatch, which was wrong, and which is why you had trouble
  200. | understanding my postings.
  201.  
  202. If I was confused, it was because Bob hadn't made his ground rules
  203. clear. The traditional OO languages have used both the O.M syntax, and
  204. mono-method dispatch (at the language level; I do not dispute that could
  205. have constructed multi-argument method selection on top of that).
  206. Without evidence, why should I have believed that he meant this
  207. ``non-standard'' interpretation?
  208.  
  209. | All of what I said was quite clear with a good
  210. | understanding of the issues involved and their context.
  211.  
  212. And when you are explaining new and different ideas to people,
  213. it's usual to assume that they *don't* already understand what you want
  214. to say. Perhaps this is a lesson for all of us; try and make it clear
  215. what you mean and what you're asking; don't assume the other has access
  216. to technical knowledge that you have been inventing; give references to
  217. your source material.
  218.  
  219. -- On finance ---------------------------------------------------------
  220.  
  221. | But don't worry, my consulting fee is only $500 an hour and I'll just bill
  222. | you;-)
  223.  
  224. The billing (if not the cooing) will be mutual, I'm sure :-)
  225. --
  226.  
  227. Regards, Kers.              | ``Remember Thor Five!'' (Earthman, Come Home)
  228.