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

  1. Path: sparky!uunet!olivea!hal.com!decwrl!csus.edu!netcom.com!objsys
  2. From: objsys@netcom.com (Bob Hathaway)
  3. Newsgroups: comp.object
  4. Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
  5. Message-ID: <-6jnf=-.objsys@netcom.com>
  6. Date: 1 Sep 92 22:54:27 GMT
  7. References: <KERS.92Aug21150658@cdollin.hpl.hp.com> <t5anrkq.objsys@netcom.com> <BEVAN.92Aug28083247@tiger.cs.man.ac.uk>
  8. Organization: Object Systems
  9. Lines: 55
  10.  
  11. >In article <31cnnr+.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
  12. >   [ use CLOS terminology in preference to Bob + Coplien ]
  13. >
  14. >   Then we'd be left with the more verbose but precise: "multiply-polymorphic
  15. >   methods" terminology.  People might still get confused over whether
  16. >   "methods" referred to CLOS, classical OO or some other kind of method.
  17. >
  18. >So?  Do you claim that if we all adopt your terminology there will be
  19. >no confusion?
  20.  
  21. Ok.  If there's confusion I won't add to it.  I will use the unabbreviated
  22. terms multiple-argument dispatch or multiply-polymorphic methods when
  23. applicable.  This makes clear the intended meaning without adding superfluous
  24. orthogonal detail.
  25.  
  26. >   CLOS stores methods specialized to a class with that class anyway. 
  27. >
  28. >Shouldn't that be "CLOS stores methods specialized to _classes_ with
  29. >_those_ classes anyway" as the whole point is that it allows you to
  30. >specialise on more than one argument.  Anyway, what does it matter how
  31. >it is _implemented_, it is the semantics that are important.
  32.  
  33. Nope, storing it based on the first argument specializer is simple because
  34. of the left-to-right priority.  The implementation I was referring to came
  35. from a subset implementation of CLOS and helps with reflection by allowing
  36. all methods specialized on a class to be accessed or listed together.  This
  37. makes sense with a left-to-right argument specialization precedence which
  38. I believe emulates receiver priority.  I mentioned it to show the close
  39. semantic similarity between the approaches.
  40.  
  41. For example:
  42.  
  43. 1) fn(A a, B b, C c, D d);    // CLOS
  44. 2) class A{
  45.      fn(B b, C c, D d);
  46.    };
  47. 3) fn(A a, B b, C c, D d);    // ordinary function
  48.  
  49. 1) is not symmetrical, in fact it is almost the same as 2) but the CLOS style
  50. is still enforcing a left to right priority scheme for the rest of the
  51. parameters.  In 2), The class member function does specialize on its receiver
  52. but is typically symmetrical for the rest of the arguments.  3) is truly
  53. symmetrical because it is a function and treats all arguments equally.
  54. Intercessory protocols can be used to provide arbitrary orthogonal argument
  55. matching but the defaults still define typical usage.
  56.  
  57. So CLOS' approach to encapsulation - functions with complete access to all
  58. specialized (and perhaps non-specialized) arguments - is irrelevant from
  59. an argument matching perspective.  And I still disagree with the dropping
  60. of protection on all but the first object since per-object protection is
  61. (reasonably) required for the separation of types and classes and IMHO without
  62. this separation a language is of little use for advanced applications.
  63.  
  64. bob
  65. objsys@netcom.com
  66.