home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / object / 3432 < prev    next >
Encoding:
Text File  |  1992-09-07  |  6.5 KB  |  123 lines

  1. Newsgroups: comp.object
  2. Path: sparky!uunet!decwrl!csus.edu!netcom.com!objsys
  3. From: Bob Hathaway <objsys@netcom.com>
  4. Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
  5. Message-ID: <q9mnb_l.objsys@netcom.com>
  6. Date: Sat, 05 Sep 92 01:15:41 GMT
  7. Organization: Object Systems
  8. References: <a6bb2744@infoage.com> <45jnpm_.objsys@netcom.com> <KERS.92Sep3100309@cdollin.hpl.hp.com>
  9. Lines: 112
  10.  
  11.                   [Don't read the P.S.'s on this one!]
  12.  
  13. In article <KERS.92Sep3100309@cdollin.hpl.hp.com>, kers@hplb.hpl.hp.com (Chris Dollin) writes:
  14. > >   ....................................................  This means the
  15. > >   object-oriented constructs are simply used to simulate and model the
  16. > >   real-world.  For example, the "world" will enforce an equal and opposite
  17. > >   reaction whenever an object undergoes some force in the world model.
  18. > >
  19. > >Isn't this use of a ``world'' a violation of the object-oriented model you
  20. > >propose? 
  21. >
  22. >   Absolutely not.  It is a perfect use of object-oriented technology as I've
  23. >   already given you many examples and explanations of.
  24. >
  25. >If that's your idea of perfection in an object model -- resolve difficulties by
  26. >having an additional object which handles all the things that local objects
  27. >can't handle -- then you and I have remarkably different notions of perfection,
  28. >object models, and what constitues a ``natural model'' of the world -- again,
  29. >if you recall, this being where we came in.
  30.  
  31. This paragraph is just to show tenability for the approach *I* was advocating.
  32. To keep things very simple, if one has a graphical model in which objects
  33. exist (or are mapped into) then there must be a coordinate "space".  For
  34. example, it is common to use a spacial partitioning representation which
  35. keeps track of various object's positions in space.  Then its easy to see
  36. when objects come in contact or to apply (or to have the objects apply)
  37. forces.  This space is therefore an object and can even be viewed as a
  38. container.  It can enforce laws such as: two objects cannot occupy the same
  39. space at the same time.  The objects themselves could enforce such laws but
  40. the space must still exist nonetheless.  And the objects deciding for
  41. themselves has the problem that they can do anything.  This is not a problem
  42. with a controlling "space" (universe, world, or whatever) that ensures all
  43. laws are enforced.  This is a "natural" solution since it fits in with the
  44. real world well (objects do exist and do *occupy space* whether one
  45. subjectively understands or believes this or not) and is a classical solution.
  46.  
  47. >It's never been clear to me whether you've been arguing from the *descriptive*
  48. >stance (``this is how certain languages *are*''), the *prescriptive* stance
  49. >(``this is is how languages *should be*''), or the *analytic* stance (subcase
  50. >of descriptive; ``this is how languages *could be seen*'').
  51.  
  52. I was arguing from a general position: "this general facility can do ...,
  53. ... does it this way, ... does it that way.  Why are people pointing to ...
  54. when it is weaker than the general case and since the latter is what's
  55. important?"  When none of the ...s do it well enough I try to do something
  56. about it and carefully consider *constructive* feedback.
  57.  
  58. >Thus, C++ and other statically typed OO languages *do* only dispatch on one
  59. >(the ``first'') argument [anyone have a counter-example?], but they *need not*
  60. >-- that is, static typing does not conflict with many-arg dispatch.
  61.  
  62. Static typing does interfere with multiple argument dispatch.  Just like C++'s
  63. multiple-inheritance interferes with virtual's contra-variance and C++'s
  64. implementation of virtual base classes interferes with downcasting, downcasting
  65. interferes with C++'s ability to perform multiple argument dispatch with
  66. virtuals (meaning all overriding signatures must match exactly).  And C++ is
  67. a perfectly good example of a statically typed (no types exist at run-time)
  68. OO language.  To spell it out completely,-) all statically typed OO languages
  69. will suffer from this "conservative estimate" problem and *obviously* static
  70. and dynamic functions *always* switch on all argument types available either
  71. statically or dynamically (with static overriding as the special substitution
  72. case under discussion).  [8th time]
  73.  
  74. >fact, I don't think it's a ``trivial static efficiency trick'' -- given the
  75. >(a) alternative, such as CLOS-style multi-methods, which are quite hard to
  76. >implement efficiently in the general case, it's a rather elegant solution.
  77.  
  78. Its not very hard since there are loads of common optimization techniques but
  79. it can take a little longer.
  80.  
  81. >Regards | "Always code as if the guy who ends up maintaining your code will be
  82. >Kers.   | a violent psychopath who knows where you live." - John F. Woods
  83.  
  84. Regards | "Always seamlessly and elegantly implement your well thought out
  85. Bob.    |  design and never just "code" lest you be judged by the consequences
  86.         |  of your own actions." - S. Engineering
  87.  
  88. P.S.  I'm truly sorry, but I can't resist:
  89.  
  90. >[Bevan: he (like Chris) couldn't understand OO message "multi-methods"]
  91. >
  92. >   Maybe you should consider this issue further before posting any more
  93. >   specifically on this subject.  It appears to me you're not even close
  94. >   and I'll often assume someone is when they discuss a subject.
  95. >
  96. >At the risk of appearing as arrogant as the above: ditto
  97. >
  98. >bevan
  99.  
  100. Considering the number of mistakes made by Chris on this subject (arg matching)
  101. and your ambiguous referent (which I thought you disapproved of, Steve):
  102.  
  103.                      AT LAST WE AGREE!
  104.  
  105. For background, bevan is an old outspoken mathematician/functional-oriented
  106. person while I am an outspoken OO person.  We first met when bevan argued
  107. against natural language "like" programming langauges (Pascal/Ada/Smalltalk
  108. were some of my examples along with some extensions) and he even went so
  109. far as to claim that natural language interfaces to databases (which allow
  110. anyone to easily access a database) were a bad thing!  Chris and I first got
  111. into it when Chris claimed that hierarchical restrictions on packages were a
  112. good idea!  [This hasn't been popular lately and nor was it with me back then]
  113.  
  114. P.P.S.  I've done all of this argument matching stuff before (including
  115.   something like the CLOS style) so its not really fair (to Chris or Steve).
  116.  
  117. P.P.P.S.  I'll have to relookup objectivism.  I thought they included
  118.   ridiculous principles such as "universal truths" and not just scientifically
  119.   measurable and observable universal laws.  Because I draw the distinction
  120.   between the subjective and the objective I don't believe I'm in their camp.
  121.  
  122. P.P.P.P.S.  As usual, my company doesn't even know about my postal activities!
  123.