home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / object / 3524 < prev    next >
Encoding:
Text File  |  1992-09-12  |  3.8 KB  |  79 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!wupost!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: <a8wnd++.objsys@netcom.com>
  6. Date: Sun, 13 Sep 92 00:56:38 GMT
  7. Organization: Object Systems
  8. References: <a6bb2744@infoage.com> <45jnpm_.objsys@netcom.com> <KERS.92Sep7094418@cdollin.hpl.hp.com>
  9. Lines: 68
  10.  
  11. In article <KERS.92Sep7094418@cdollin.hpl.hp.com>, kers@hplb.hpl.hp.com (Chris Dollin) writes:
  12. [On static typing and multi-methods]
  13.  
  14. I'm giving up if we don't see eye to eye on this after this posting!-)
  15. Static typing means types are available at compile-time.  Saying a
  16. language is "statically typed" infers it is not "dynamically typed" which
  17. means types are available at run-time.  Dynamically typed languages dispatch
  18. based on the dynamic types of arguments.  This is *not* possible with
  19. (strictly) statically typed languages because dynamic types are *not*
  20. available.  So some clever people come up with some tricks (such as virtual
  21. functions) which are dynamically bound but are still resolved at compile/link
  22. time.  And some maintain types in their programs (a la Coplien) and emulate
  23. dynamic typing in an ad hoc way.  In other words (and for the last time), you
  24. can't switch on dynamic types if (by definition) they aren't there!  And
  25. multi-methods are dispatched at run-time (dynamically).  And your (elided)
  26. example doesn't seem relevant.
  27.  
  28. >[I'm sure I've asked you this before, Bob, but what's the difference between a
  29. >``dynamic'' function and a ``static'' one?]
  30.  
  31. Whether the method/function selection is performed at compile-time (static
  32. typing, e.g. C++, Eiffle) or at run-time (dynamic typing, e.g. CLOS, Smalltalk).
  33.  
  34. >   [8th time]
  35. >
  36. >8 repetitions of the same presumed information does not teaching make.
  37.  
  38. Excuse me, but I think this makes 10.  And its not "presumed" information.
  39.  
  40. >   Chris and I first got into it when Chris claimed that hierarchical
  41. >   restrictions on packages were a good idea!  [This hasn't been popular 
  42. >   lately and nor was it with me back then]
  43. >
  44. >Perhaps you could also explain to me what you think I meant at the time, since
  45. >your description of it does not accord with my thinking about packages *now*,
  46. >and I don't think I've moved position much in the past couple of years.
  47.  
  48. I simply argued there should be no hierarchical restriction and you argued
  49. there should be because generics could always be used to solve the problem.
  50. I believe I was pointing out the extreme convolution and added complexity
  51. required to do so as opposed to the "natural" graph solution.
  52.  
  53. >CLOS sees there being two activities, that of defining/declaring generic
  54. >functions (which are about interfaces) and that of defining/declaring methods
  55. >for implementing that functionality *for particular argument combinations*.
  56. >
  57. >Hence my remark that methods, on their own, were NOT enough; you need [*1] the
  58. >generic functions to invoke them.
  59.  
  60. Thanks for the CLOS summary.  But I don't see why generic functions are
  61. necessary.  Just leave them out, Chris and you'll see all is well.  Really,
  62. try an example by declaring a generic function and methods and simply delete
  63. the generic function (which I'm not sure is even required in CLOS).  I can
  64. see how to implement the system and I don't see any loss - not with method
  65. combination, individual methods, or anything else - all is still well.
  66.  
  67. bob
  68. objsys@netcom.com
  69.  
  70. P.S.  The elided generic function is left as an exercise to the reader.  Any
  71.   *conflicts* may be posted.
  72.  
  73. P.P.S.  I haven't had time to consider Barry Margolin's response about
  74.   CLOS's ability to handle the separation between type and class, but
  75.   I recall his suggestion was really a separation between class specification
  76.   and body and not really a type/class separation (or multiple-(simultaneous)
  77.   implementations per type).  He said to just use accessor functions instead
  78.   of direct instance variable access.
  79.