home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3268 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  33.9 KB

  1. From: kers@hplb.hpl.hp.com (Chris Dollin)
  2. Date: Thu, 20 Aug 1992 11:05:08 GMT
  3. Subject: Re: Re: Type Conformance and Inheritance (was O.M() versus M(O) notation)
  4. Message-ID: <KERS.92Aug20120508@cdollin.hpl.hp.com>
  5. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  6. Path: sparky!uunet!usc!sdd.hp.com!hpscdc!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
  7. Newsgroups: comp.object
  8. References: <1992Aug5.162329.22871@ucunix.san.uc.edu> <KERS.92Aug19111407@cdollin.hpl.hp.com> <+_#n6_a.objsys@netcom.com>
  9. Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
  10. Lines: 667
  11. In-Reply-To: Bob Hathaway's message of Thu, 20 Aug 92 02:27:05 GMT
  12. Nntp-Posting-Host: cdollin.hpl.hp.com
  13.  
  14.  
  15. WARNING. Long (600+ lines). This discussion has turned rather philosophical;
  16. mail me if you think it should be moved to email or to a different newsgroup.
  17. It also won't make all that much sense if you haven't seen the previous
  18. messages, although part of the length of *this* message is due to quoted
  19. material to try and preserve some context. Caveat Lector.
  20.  
  21. In article <+_#n6_a.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
  22.  
  23. |In article [...] kers@hplb.hpl.hp.com (Chris Dollin) writes:
  24. |>That's true, but it works in the other direction; you *pick* a grammar to make
  25. |>the *concepts* clear in the language, rather than picking up some grammar
  26. |>that's been lying around like a dirty sock and trying to fit it onto your
  27. |>hands.
  28. |
  29. |I'm surprised you refer to our programming language's English heritage that
  30. |way; maybe you prefer Lisp:-)  Lets not get into this argument again but
  31. |everyone knows English (excepts maybe the French (ha ha, just kidding))
  32. |and it therefore comes most naturally to us; hence our languages gramatical
  33. |bias towards the imperative invocation.
  34.  
  35. I am moderately well-known for preferring Pop rather than Lisp :-) (although I
  36. perfer Lisp to English for programming). And the point about English is a
  37. serious one; it is but one of many natural languages, not all of which share
  38. its syntactic quirks (although the underlying *models* of the speakers may be
  39. the same as those of English-speakers).
  40.  
  41. And using ones natural languages syntactic biases as the basis for modelling
  42. the real world (I note that both of us seem to agree that it exists) seems
  43. shakey -- (a) were constructing *artifical* (programming) worlds, and (b) the
  44. world is not as easily described as English might have you think.
  45.  
  46. |>That's if you *assume* that the objects exists with the interface (etc). It's
  47. |>not a given, it's a choice.
  48. |
  49. |Not really.  The real world is made up of objects and they do possess
  50. |properties and attributes and etc.
  51.  
  52. I'm sorry. It is this point on which we seem to have a fundamental
  53. disagreement -- or perhaps a terminology problem. This model of the world --
  54. that there are objects, and properties, etc -- is a nice friendly (but not
  55. universal) one. But you are giving primacy to matter clumped in ways
  56. appropriate to the senses which we possess, and the real world is much, much
  57. richer than your model allows.
  58.  
  59. |Current object-oriented techniques simply use a behavioural (or
  60. |observational) approach to defining these object's externally visible
  61. |interface to the world.
  62.  
  63. They have a particular descriptive style which they use. Models are built
  64. which allow properties observed in the real world to be immitated by the
  65. object-oriented description. The objects, and the interface, are properties of
  66. the *description*, not of the *world*.
  67.  
  68. What is the OO interface of my cup? Can you enumerate *all* the methods that
  69. can be applied to it -- sorry, that it can execute? Any model you construct
  70. (OO or not) will be an *approximation* to the cup. And that's all one demands
  71. of a model -- that it be a good enough approximation.
  72.  
  73. If my cup is an object, what happens when I drop it and it breaks? Suppose the
  74. handel [Hallelujah!] comes off. Is the cup now one object? Has it changed
  75. state (lost the ``handle'' attribute, perhaps)? And the handle -- is it now a
  76. separate object, and, if so, did it exist before (maybe the aforementioned
  77. attribute)? If you take this view, suppose that the cup shatters into a
  78. lay-persons-million pieces. Where's the cup? From whence came the pieces?
  79.  
  80. I think it's easier to say here that the ``cup'' is an *abstraction*, a
  81. *model* of some part of the real world which behaves in a particular way. When
  82. I drop the cup, and it shatters, the abstract notion becomes inapplicable. The
  83. ``object-ness'' of the cup is an illusion -- it resides in our models, not in
  84. the world.
  85.  
  86. |Analyze any process and you'll find a set of objects interacting with each
  87. |other.  This occurs at all levels in the real world.  I don't see how this is
  88. |questionable, it is an objective fact.  Do you really dispute this?
  89.  
  90. I translate this as ``I can force-fit my obect model onto anything that
  91. happesn in the world''. When the cup breaks, what are the objects, and how are
  92. they interacting? How formal are you prepared to make this model? If it's just
  93. a handy way of speaking, then you don't need to get formal, but your basis for
  94. claiming any sort of deep reality vanishes. If it's actually a precise
  95. description, then you need to supply a whole lot of detail -- just saying
  96. ``you'll find a set of objects interacting with each other'' isn't good
  97. enough.
  98.  
  99. How do you identify the objects? The interactions? Even the notion of
  100. ``process'' is part of our *description* of the world.
  101.  
  102. |Anyway, there are many ways of viewing this objective reality.  I'll
  103. |admit this may be disputable.
  104.  
  105. On the contrary, I strongly agree that there are many ways of viewing the
  106. objective reality. But I don't regard the lexical coincidence (objective ~~
  107. object-ive) as particularly compelling argument.
  108.  
  109. |All object-oriented texts justify a view based on the real world, try Booch
  110. |OO Design or Rumbaugh et al OO Modeling and Design for some examples and for
  111. |a jillian reasons why.
  112.  
  113. For the purposes of doing an object-oriented design (or indeed any other kind
  114. of design), of course you look to the real world. What point would there be in
  115. modelling a pretend one? And, to do an OO design, what more natural than to
  116. treat the world as OO? If it does the job, that's fine. But that doesn't mean
  117. that the world *is* object-oriented, or that other techniques aren't also
  118. useful.
  119.  
  120. In Fusion (if I may be permitted a note of advertisment; Fusion is the OO
  121. analysis and design method we have built here at Bristol), we carefully
  122. distinguish to stages: analysis and design. *Analysis* attempts to identify
  123. the objects and their relations, and the operations that can be applied to the
  124. system being modelled. At this stage we do *not* talk about ``methods'' and
  125. ``interfaces''; we concentrate on describing the *relationships* that hold
  126. before and after operations have been performed. It is at the *design* stage
  127. that we allocate operations to objects, and make the *choice* as to which
  128. objects have which methods.
  129.  
  130. After all, there are many designs that can satisfy the same analysis, and they
  131. can present objects with different interfaces. Which one you pick is going to
  132. depend on various factors -- the existance or otherwise of existing
  133. vocabularies, and the target programming language, to name but two.
  134.  
  135. |>In the software reality, M can certainly be the doer; consider CLOS, for
  136. |>example, with generic functions rather than objects-that-know-how-to.
  137. |>
  138. |>In physical reality, doers are not "sent messages" that tell them how to
  139. |>change their state.
  140. |
  141. |Yes they do.  "Bob, go to the store" is a request for an action.
  142.  
  143. So you identify doers with intelligent (or do I mean sapient?) agents? But
  144. that makes a nonsense of your stack example -- I can talk to the dish-stack as
  145. much as I like, but nothing happens until I put the tray on the stack. Then it
  146. ``pushes'' down. You may choose to say that's an action performed by the
  147. stack, but it seems to me that you'd say that just to keep the OO model going.
  148.  
  149. And a single example is hardly enough to justify such a sweeping statement.
  150. What message is sent to the clouds to tell them to rain? What message to the
  151. clock, to tell it another second has passed? What message to the river, to say
  152. ``flow downward!''? What message to the atom of tritium, to say ``decay!''?
  153. What message to the iron, to say ``To the magnet!''?
  154.  
  155. Now, you can tell me that there are indeed messages for these things. But if
  156. you do, I am likely to say that you have stretched the concept of ``message''
  157. so far that it no longer seems to say very much; if any physical interaction
  158. is a ``message'', then yes, perhaps your objects are real (and sub-atomic),
  159. but we may as well use the terminology of physics, not computer science.
  160.  
  161. |And doers don't just change state, they can perform actions or even just
  162. |think about things although you might refer to the latter as a state change
  163. |(but I still don't like connectionists (just kidding :-)) and they are
  164. |usually quite capable of inciting their own actions.
  165.  
  166. So, at the very least, your objects are autonomous processes -- unlike the
  167. object models supported by Smalltalk, C++, and CLOS?
  168.  
  169. |The imperative of making requests and issuing commands is ubiquitous, so I
  170. |dispute the logic of your above statement.
  171.  
  172. Well, it's ubiquitous in human society, I'll grant you that. But us humans
  173. form a pretty small part of the real world. Even if we include the entire
  174. biosphere in the request/command world, it's *still* a tiny part of the real
  175. world.
  176.  
  177. If what you're saying is that the imperative metaphor pervades the kinds of
  178. systems which we wish to model on a computer, and consequently the notions of
  179. ``doers'' and ``messages'' are sueful enough to be parts of our language
  180. vocabulary, well, OK; but that's a pretty far stretch from saying that objects
  181. are real, and that THE real world behaves in an OO fashion.
  182.  
  183. |>Even the normal (English grammar) notions distinguish the
  184. |>doer (which performs the action) from the done-to (which suffers it).
  185. |
  186. |The many examples, such as the imperative request for me to go to the store,
  187. |show this not to make sense so again I'll have to dispute your logic and ask
  188. |for an elaboration.
  189.  
  190. ``Bob, break the cup!''. You -- Bob -- are the doer. The cup is done-to. (One
  191. of you is the object -- ha! -- and the other the subject of the sentence ``Bob
  192. breaks the cup'', but I can't recall which is which and the dictionary entry
  193. is sufficiently obscure that I can't tell from that, either. Bah.)
  194.  
  195. |>That's one way of describing the situation, yes. But it's not a matter of
  196. |>natural law; it's a matter of how you choose to *describe* stacks. Certain
  197. |>things happen, and certain relationships hold. Attributing control to one or
  198. |>the other "thing" in the description is a matter of *choice* -- you choose
  199. |>the description that seems best fitted to your needs.
  200. |
  201. |Scarce aggreement if any on this from me.  You are an object, the pencil on
  202. |my desk is an object, and so on.  These are not subjective views, you and the
  203. |pencil have definite properties and attributes which work over you as a whole.
  204.  
  205. I'm not sure if we'd use ``subjective'' in the same way. I agree that the
  206. thing you call a pencil has definite properties which belong to it-as-a-whole.
  207. I agree that this entitles you to call it an ``object'' -- because it's an
  208. appropriate descriptive technology to use. (Here, I'm using the informal --
  209. lay-persons -- sense of ``object'', not the computational one.) But this view
  210. is *abstract*, it's a way of carving up the world to make sense of our
  211. perceptions; in that sense it *is* subjective.
  212.  
  213. If objects are ``real'' -- if being an object is a property of the *world*,
  214. not of a *description* of the world -- then we'd all carve the world into the
  215. same set of objects, right? But I don't think we do.
  216.  
  217. |Do you have a better point of view.  The functional one seems even further
  218. |from reality to me but I do keep an open mind.  Do you have a convincing
  219. |argument that there is a better and more natural way of viewing the world?
  220. |I'm all ears.
  221.  
  222. Better [point of view] for what? Look, my argument is primarily that *there is
  223. no best view* -- that you pick a descriptive technique that fits the problem
  224. and solution domains. The OO view is good for a class of systems, and I have
  225. no objection to *using* it *for that class*. I am not *advocating* a
  226. functional viewpoint, but I am advocating that it have equal status with other
  227. viewpoints -- that there's nothing *inherently* wrong with it.
  228.  
  229. As for a better and more natural way of viewing the world, again, what do you
  230. mean by ``better''? Better for what? And what does ``natural'' mean? There are
  231. at least two views (ho!) on the latter:
  232.  
  233. -- Natural means ``what we're used to''. Heavens, different (programming)
  234. languages have different natural idioms: for Pop, it's creative use of the
  235. open stack, partial application, and properties; for Lisp, it could be
  236. effective use of lists and higher-order functions; for Snobol it's the
  237. exploitation of pattern-matching; for C it's, ur, pointers and address
  238. arithmetic. The approach used in one language is completely unnatural in the
  239. other. Nevertheless, each approach is valid in its language. In this sense,
  240. being ``natural'' just means that it's a tool you know how to use effectively;
  241. nothing to do with the real world.
  242.  
  243. -- Natural means ``appropriate to the real world''. Now, humans see the world
  244. in a particular way, because they've been ``designed'' to fit into it at a
  245. particular scale and using a particular set of senses. [There's a newsgroup
  246. for discussing what ``designed'' might mean here, and I don't propose we
  247. side-track down that line here.] We've got cultural and generic machinery that
  248. makes certain concepts seem to belong out there -- in the world -- rather than
  249. in our heads. But our notions of natural *break down* when we start to explore
  250. environments grossly different from those we grew up in; the very small, the
  251. very large, the very fast, the very hot, the very cold. Quantum mechanics is
  252. ``natural'' for describing the very small, for example.
  253.  
  254. So I don't think that the human notion of natural coincides with the behaviour
  255. of the real world. And our programs are not confined to the world which humans
  256. find natural; X-ray crystallography and galaxy-smashing simulations are just
  257. as proper subjects for computation as bank accounts and travel arrangements.
  258. (Incidentally, note that a ``bank account'' might well be an object in a
  259. program. Is there a ``bank account'' object in the real world? Well, yes, if
  260. you realise that a particular organisation is just as real as a cup. But bank
  261. accounts aren't ``natural objects'', they're invented ones, like theatre
  262. bookings and your employment contract.)
  263.  
  264. |>Now, certainly the choice is not *arbitrary* -- it's nice if the description
  265. |>is internally consistent, nicer if it also describes the kinds of things that
  266. |>you want it to describe. But that doesn't mean that there's only one choice.
  267. |
  268. |Again, if I can show an objective reality such as: the universe is made up
  269. |of objects and these objects have properties and attributes that are
  270. |objectively discernable, measurable, and workable then there is only
  271. |one objective, true description.
  272.  
  273. Yes, *if* you can show this. Since I think it's a false statement, I can let
  274. you can deduce anything you like from it.
  275.  
  276. |>I've just ``give my cup a little push''. (I was taling to someone about
  277. |>actions as objects, and how real they were, and this piece of idomatic English
  278. |>just popped out.) It suggests that actions can be -- are -- objectified in
  279. |>(some) natural language uses. Are they still not in the real world?
  280. |
  281. |No, they are not.  You as an object can push the cup.  If you design an
  282. |artificial reality and can say ``give my cup a little push'' and it moves
  283. |a little this is magic, not metaphor.
  284.  
  285. The point here is that speakers (I generalise from an excellent example :-)
  286. *already* treat actions as real, as objects; it is *natural* for them. I know
  287. I'm pushing the cup in my example. Suppose I have a metal cup and an
  288. interesting arrangement of electromagnets, such that when the current flows
  289. the cup is thrown several feet in the air. What pushes the cup? The magnets?
  290. Well, that's one view -- seems like magic to me, though. The magnetic field?
  291. Yes, that'll do me -- but if only objects cam push, then the field is an
  292. object. It's invisible, inaudible, intangible (except to the cup) -- not the
  293. notion of object I would have thought was ``natural''.
  294.  
  295. The remark about artificial reality is, I think, irrelevant.
  296.  
  297. |In our minds we have a notion of push but it is based on all the ways all the
  298. |different kinds of objects that can push other objects.  There must be a
  299. |pusher and almost always a pushee for push to work because this is the way it
  300. |works in reality.
  301.  
  302. The notion of push is an abstraction, like the notion of cup. The actual push
  303. is real, as is the actual cup.
  304.  
  305. |>| In other words, there aren't little "pushes" floating around but there are
  306. |>| stacks that one can push an object onto.
  307. |>
  308. |>Your stack is just as much an abstraction as my push. Stacks don't come with
  309. |>little labels saying "I am a stack" (although I suppose that they would if
  310. |>they were International Rescue equipment); we call them stacks because they
  311. |>relate in a particular way to the rest of the world.
  312. |
  313. |But there are stacks in the real world and there are not "pushes".
  314.  
  315. Ie, you do not admit that decoupling the notion of ``push'' from ``pusher'' is
  316. a fruitful one. This is not a matter of natural law. *I* think pushes are
  317. real; I've been on the receiving end of several. I think magnetic fields and
  318. smells are real, too, and I don't think the lay notion of ``object'' is a good
  319. descriptive tool for them.
  320.  
  321. |>Oddly enough, the stacks I know of in ``real life'', the archetypal push-down
  322. |>stack of restaurant trays, are incapable of pushing objects -- something else
  323. |>has to do the pushing.
  324. |
  325. |Then you know how to push the tray.  I think you're arguing either the
  326. |behavioral interface approach or the choice of interface.  If you want the
  327. |stack to be more like the stack you're referring to then make it an aggregate
  328. |of movable parts and then define the spatial relationships and dynamics of
  329. |the system; it'll work just fine.
  330.  
  331. Yes, and there are no ``objects'' knowing what to do in this description; just
  332. plain objects and relationships.
  333.  
  334. |Your argument sounds like a choice of interface argument; the behavioral
  335. |interface can be viewed as merely a simplification or abstraction of the real
  336. |physical system involved.
  337.  
  338. Exactly. It's an abstraction constructed according to chosen rules.
  339.  
  340. |And the aggregate parts do have properties and characteristics, too.  They
  341. |should be part of their interface to the world and not separated as with the
  342. |unencapsulated approach.
  343.  
  344. Sorry, I'm lost. Are we talking about tray stacks or programmatic stacks now?
  345. And how come we've started talking about encapsulation -- a concept to be
  346. applied to *descriptions*, rather than an object in the real world?
  347.  
  348. |>| The doer is clearly defined in the most natural way known to us.  If
  349. |>| there is no object (entity or whatever) which is to explicitly carry out
  350. |>| this command, then we could have:
  351. |>
  352. |>Now you are applying the terms of our world model (with intelligent agents
  353. |>[which, I suspect, is a model we share, irrespective of its truth]) to
  354. |>software concepts (``objects'') in a way you need to convince me is
  355. |>well-founded.
  356. |
  357. |With VR this is trivial.
  358.  
  359. Sorry, I don't understand. What has VR (I presume ``virtual reality'') have to
  360. do with the argument? If you are saying that VR *has* applied the notions of
  361. intelligent agents, all that says is that the notions been applied, not that
  362. it is intrinsically correct in other domains.
  363.  
  364. |Most other software domains also deal with or describe real world entities
  365. |and therefore modeling these entities is the most important issue involved.
  366.  
  367. Real world ``entities'' like bank accounts, weather forecasts, contracts,
  368. programs, screen displays, marriages, perhaps? Yes, modelling the world
  369. is important in software development -- irrespective of whether the world, the
  370. program, or the language in which it's written, are OO.
  371.  
  372. |Also please be careful with the term "world model".  In AI this is the model
  373. |or context in your head and I don't think this is the way you're using it.
  374.  
  375. There's probably several different uses of the term ``model'' knocking around
  376. in my note (and its predecessors); if I or the context don't disambiguate
  377. successfully, I'm sorry.
  378.  
  379. Usually by a ``model'' I mean a (formal or informal) construction, which can
  380. be manipulated in ways related to the real-world operations it models to
  381. generate answers which are related in a similar way to the real-world results
  382. of the operations.
  383.  
  384. By ``our world model'' I meant the model of the world which humans seem to
  385. share. It's certainly in my head.
  386.  
  387. |>I don't need any references to reality. I have one here now :-)
  388. |
  389. |True, that is why OO and OO systems are so trivial to build.  Even better
  390. |with AI.
  391.  
  392. If you find them trivial to build, then you have access to rather more design
  393. and coding prowess than I can lay claim to.
  394.  
  395. |>Reality is more slippery than you seem to think. My analysis would have
  396. |>``bearing on reality'' if it let me make (testable) predicictions about
  397. |>reality that were (by and large) true. (``By and large'' because the world is
  398. |>far too big for any computer model we build to catch everything.
  399. |
  400. |I don't see this.  I can break the real world up into objects even starting
  401. |with atoms, subatomic particles, and quarks, and can work my way up to any
  402. |object that has discernable properties, can you do so for your model?
  403.  
  404. Since were talking about a hypothetical analysis I might do, the answer is
  405. unquestionably ``maybe''. But this break-up you mention; you'll put all of
  406. this in the object-oriented code, yes? No? Perhaps you'll be content with an
  407. abstraction that does the job well enough. So will I.
  408.  
  409. |> Probably no model contained *in* the world can model *all* the world.)
  410. |
  411. |Interesting claim, can you prove it?
  412.  
  413. If I could, I wouldn't have said ``probably''. Isn't it a standard
  414. philosophical chestnut? A universal model *in* the universe would have to
  415. contain a model of itself modelling itself modelling .... Well, the thing
  416. *might* go to a limit. Without a convincing example, I wouldn't bet on it.
  417.  
  418. [about unnatural designs being harder to understand]
  419. |You missed the point.  It is that if it is natural, then its more likely that
  420. |someone else can understand it.  Its like what you said below but since
  421. |there's no argument, I'll delete it.
  422.  
  423. But my point here is that ``natural'' is not a given.
  424.  
  425. |>It's certainly *a* way. It might (or might not) be an *excellent* way. But
  426. |>it's not the *only* way, and it might not be the only *excellent* way. Decrees
  427. |>do not establish truth.
  428. |
  429. |Actually, there's an incredible building amount of evidence that OO systems
  430. |are more maintainable, hold up better over time, are easier to understand,
  431. |etc.  Its the old style unencapsulated approach that seems to have failed
  432. |miserably (the software crisis), no?
  433.  
  434. Oh, I've no particular argument that OO programs seem to have various
  435. advantages over non-OO programs. But this could just as well be because they
  436. are better organised internally (for example, with data-hiding -- a concept
  437. not supported by the real world), rather than because in some sense they
  438. ``fit'' the real world.
  439.  
  440. Is a complex number an object? An angle? An integer? Are any of them ``real''
  441. (choke)? Would you excude them from OO systems on this basis?
  442.  
  443. |>I don't understand what you mean, then. If we're talking about programs ``the
  444. |>computer'' does *all* [modulo trivia about I/O handling, etc] the doing -- the
  445. |>"objects" are simulated by the machine. Well, if it can simulate objects, it
  446. |>can simulate operations, too, and all that describing this as "punting" does
  447. |>is to say that you don't like it [and cast aspersions on one of Oxfords most
  448. |>enjoyable activites, to boot].
  449. |
  450. |No.  In OO programs the objects carry out the operations; the computer is
  451. |transparent.
  452.  
  453. Well, that depends on what level you want to look at, doesn't it?
  454.  
  455. |This is not so with your model.
  456.  
  457. In my model the messages carry out the operations; the computer is
  458. transparent. [Actually, since I haven't presented a model, you can't say it
  459. isn;'t so, and I can't say it is.]
  460.  
  461. |Also, if I write an imperative algorithm without an explicit doer, such as:
  462. |  take this
  463. |  do that with it
  464. |  put this here
  465. |  do that
  466. |  you're done
  467. |
  468. |There is the implicit imperative you for each instruction.  If I now reuse
  469. |this component by following it myself, handing it to a robot to perform, or
  470. |whatever then self becomes the implicit receiver.  In OO any such imperatives
  471. |are considered with an implicit self making this algorithm *completely
  472. |reusable*.
  473.  
  474. It doesn't need OO to make this reusable; all it takes is an implicit
  475. parameter, or an explicit one if you like.
  476.  
  477. |It can be used by any actor (object).  If anyone else needs to carry out an
  478. |operation in the algorithm, the algorithm can specify that also with O.M....
  479.  
  480. Or with wahtever notation one uses.
  481.  
  482. |Notice that makes the receiver special (which it should be anyway)
  483.  
  484. But Bob, that's exactly the point that's being argued -- should there *be* a
  485. receiver, specially marked? Not whether or not you *can* use that notation,
  486. and have ``receivers'' as a concept, but whether that's a *necessary* part of
  487. OO. If you take ``the receiver should be special'' as an axiom, of course its
  488. going to appear as a theorem. But PG (I think) and myself are saying that *we
  489. dispute your axiom* -- a distinguished receiver is not *necessary* and is not
  490. *sufficient* for object-oriented dispatch.
  491.  
  492. |and by not including it as a parameter WE HAVE A BETTER MODEL with
  493. |the O.M ... or even (O).M ... (implied receiver).
  494.  
  495. Yes, if it works, it's OK. But is that *necessary*? If I wish to model without
  496. having distinguished receivers (as, for example, makes sense when doing
  497. arithmetic on generalised numbers), why should I use this unbalanced notation
  498. that makes one argument more ``important'' than the other?
  499.  
  500. |Again, discerning the doer is more clear AND more reuasable AND closer to
  501. |reality.  Don't get this without discerning the receiver, huh?
  502.  
  503. Well, it's only clearer if that's how the model works, it has sod-all to do
  504. with reusability, and it's only closer to reality if the portion of reality
  505. you're modelling is modelled that way.
  506.  
  507. |>Perhaps I have mis-spoken; the messages are not the receivers, they are the
  508. |>doers. You seem to be refusing to take actions as objects; well, that's a
  509. |>choice. It may be a convenient and frutiful choice; well and good. That
  510. |
  511. |No, it has a bearing on reality since the objects in the artificial world
  512. |are the actors, the computer is transparent.  This matches reality,
  513. |your approach doesn't.
  514.  
  515. Shall I say this clearly? The *approach* I am arguing is *the acceptance of
  516. diversity* -- in both the world and our descriptive notations. You are
  517. insisting that actions are not real (not objects, and the real world consists
  518. of objects). Let me put this clearly: I think you're wrong, that you are
  519. excluding other approaches, despite their usefulness; and that this does not
  520. strengthen the naturalness of your approach, it weakens it.
  521.  
  522. Diversity seems to have done pretty well in biological (``natural'') systems.
  523. Don't knock it.
  524.  
  525. |>doesn't make it the *only* choice, and I read your arguments as saying
  526. |>``object orientation is not only useful, it's *right*''.
  527. |
  528. |But it matches reality.  If you have a better way of modeling and or
  529. |simulating it speak up.  This functional orientation just seems much
  530. |further from the truth.
  531.  
  532. I have, and I will; it is this; *use whatever techniques work*. You will find
  533. that no one technique will do everything. (Except this one, of course.)
  534.  
  535. |>In the presence of multi-methods, why should one argument to a message send
  536. |>have a special syntactic position?
  537. |
  538. |Because it is the object performing some action, as is always the case in
  539. |the real world.
  540.  
  541. Not with multi-methods, it isn't; that's the point.
  542.  
  543. |>Well, "normal" OO languages (Smalltalk, C++, Simula) *do* only ``overload on
  544. |>the first parameter'' -- that is, the action that is performed is determined
  545. |>by the "message" and the (type of the) first parameter (the receiver), which
  546. |>may in consequence be granted special syntactic status.
  547. |
  548. |Smalltalk does so because it is statically typeless and C++ is statically
  549. |typed.  I consider both weak because of this.  And I'm not up on my
  550. |Simula.  The languages here obviously have O.M... notation and use
  551. |multi-methods, they always have.
  552.  
  553. They *don't* have multi-methods. They *never* have. Bob, is it possible we
  554. have drastically different notions of what ``multi-method'' means? My notion
  555. is taken from CLOS, on which I'm no expert but I think I understand the
  556. basics.
  557.  
  558. |>Granted, the selected action may then perform further dispatch, if that's what
  559. |>the programmer has written. But that's not something the language does *for*
  560. |>you, whereas in CLOS the action is determined by the "message" (the generic
  561. |>function) and, in principle,  (the types of) *all* the parameters.
  562. |
  563. |This is based on weak or contrived systems.
  564.  
  565. Sorry, don't follow -- what is based on what ``weak and contrived'' systems?
  566. CLOS does *more* for you than normal OO dispatch, which is just a special case
  567. of CLOS dispatch. I wouldn't have said that this made it ``weak'' or
  568. ``contrived''. Since it allows OO dispatch to fit into the same framework as
  569. the run-time generalisation of overloading, I would have called it a
  570. ``powerful unification''. (The run-time costs have been addressed elsewhere.)
  571.  
  572. |>It's so obvious -- and it isn't true. Yes, it's obvious, and we [humans; I'd
  573. |>not like to speak for the rest of the biosphere] are probably engineered to
  574. |>see it that way. It's certainly a handy way to carve up the world, and it
  575. |>works pretty well.
  576. |
  577. |No, I've declared it as an objective fact and have yet to see otherwise.
  578.  
  579. Your declarations tell us about your beliefs, but they don't make them true.
  580.  
  581. |>It works *so* well that we try to make things into objects at the least
  582. |>provocation. Is a classroom an object? How about a university? A nation? A
  583. |>solar system? A galaxy? A flock of birds? A river? A photon? A traffic jam? An
  584. |>ozone hole? A county boundary? A code? A (real) window? An (X) window? The
  585. |>*law* of gravity? The *force* of gravity? Magnetism? The aether? A
  586. |>(mathematical) group?
  587. |
  588. |First, try your hand at virtual reality.  That will answer your question.
  589.  
  590. You think a simulated experience will answer questions about the real world
  591. and our descriptions of it? Perhaps it will tell me about the VR designers
  592. *view* of the world, but that's not what I was asking about. What VR
  593. experience will tell me if magnetism ``is'' an object? Why couldn't a *real*
  594. experience tell me the same thing?
  595.  
  596. Or do you mean I should *program* a VR system? Great, you want me to build a
  597. model of the real world. rest assured that I will carve up said world in any
  598. way I find convenient, and I might use objects (the programming language
  599. constructs) to model various things in the world (such as magnetic fields, and
  600. traffic jams). But then I might use numbers, or groups, or procedures. If you
  601. turn round, and say, ``see! you used objects!'', because you call everything
  602. in my programming language an object, well, that's your choice, but I think
  603. the terminology would lack precision.
  604.  
  605. |If you don't base everything on objects you're a fool.
  606.  
  607. Why, how kind. [I gather from this Bob *did* mean that I should implement VR,
  608. rather than experience it.] In other words, knowing hardly anything about my
  609. programming capabilities, my scientific background, or the capabilities of the
  610. languages and hardware I'd choose to use, Bob thinks objects would be forced
  611. upon me. I disagree.
  612.  
  613. |And the rest of these examples are mostly concepts and abstractions like the
  614. |kind we work with *in our heads*.
  615.  
  616. But are they *real*? (Of course they are. They're as real as Bob's objects,
  617. anyway.)
  618.  
  619. |Yes, we can give attributes to a flock of birds even if thats not the way the
  620. |real world is broken up.  This is the subjective side, not the objective side
  621. |of objects.
  622.  
  623. It's not that it's *subjective*, it's that it's *abstract*. (Subjective would
  624. suggest that it's private to the individual.) So descriptions can contain
  625. objects that don't appear in the world, right? And you're saying that magnetic
  626. fields are only in our heads -- they're not ``out there''?
  627.  
  628. |For my own purposes I've broken the world up into transitory parts such as
  629. |real-world modeling (RWM), mental worlds (MW), and abstract worlds (AW) since
  630. |each has its own requirments and properties.  For RWMing its OO all the way
  631. |and for the rest the same applies.
  632.  
  633. I'm sure you can bend the OO style to fit, but I bet I wouldn't find it
  634. ``natural''.
  635.  
  636. |>What sends messages to a mass to tell it to exert force on the floor?
  637. |
  638. |The universe enforces universal laws in my book.
  639.  
  640. So, where you can't find an object, you attribute the messages to the
  641. universe? Where are the messages? I must admit that treating the universe as
  642. an object is a neat trick, considering that the universe is itself an abstract
  643. concept. Can you point to the universe (not just to a bit of it)?
  644.  
  645. |>What sends messages to ``1'' in ``1 + 2'' to tell it to compute ``3''?
  646. |
  647. |Define the ring of integers and export its operations (like Ada's use clause).
  648.  
  649. Yes, yes, that's programming, I don't want to know how you'd *write* it, I
  650. want to know what sends the messages. *I* think that the object ``+'' is sent
  651. the message ``run(1,2)'', and that (because all the operators take the one
  652. message ``run'' with a pair argument) that perhaps there's another description
  653. more suitable to the job.
  654.  
  655. |>Do I send messages to my cup when I fill it with tea?
  656. |
  657. |It does know something has come in contact with it.  I like the universe
  658. |idea myself for "dumb" objects and forces.
  659.  
  660. If you're taking ``the univer enforces universal laws'' as a base-point, there
  661. *are* only *dumb* objects.
  662.  
  663. |>Is the object-oriented notion of "message" appropriate to cups, tea-bags,
  664. |>waves (wet), waves (electo-magnetic),
  665. |
  666. |If it comes in contact, sure.  Physical dynamics are handled by the
  667. |universe with objects at various levels receiving the various forces.
  668.  
  669. The forces are messages? But, since the forces themselves to messages, then
  670. messages must be objects too.
  671.  
  672. |It gets more interesting with us because our senses input these forces
  673. |on contact and then interprets them using trellises and other wonderful
  674. |things.  I'd love to go on but my time's up and way past due.
  675.  
  676. Trellises?
  677. --
  678.  
  679. Regards,    | ``Wandering minstrels are fogging my brain    | Judy Tzuke
  680. Kers.       | And weird intellectuals are doing the same.'' | Higher & Higher
  681.