home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / scheme / 2041 < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.8 KB  |  54 lines
  1. Newsgroups: comp.lang.scheme
  2. Path: sparky!uunet!gatech!bloom-beacon!INTERNET!dont-send-mail-to-path-lines
  3. From: bill@cambridge.apple.COM ("Bill St. Clair")
  4. Subject: message passing vs. generic functions
  5. Message-ID: <9208171954.AA05736@cambridge.apple.com>
  6. Sender: daemon@athena.mit.edu (Mr Background)
  7. Organization: The Internet
  8. Date: Mon, 17 Aug 1992 20:57:07 GMT
  9. Lines: 43
  10.  
  11. >From: Barry Margolin <barmar@think.com>
  12. >Subject: R^4RS Authors Comments on Dylan
  13. >Message-Id: <16ii5eINNonl@early-bird.think.com>
  14.  
  15. >Regarding the notion of "smart objects" and message passing, we in the CLOS
  16. >community have basically decided that this is an artificial and restrictive
  17. >paradigm.  We believe that the essence of OO programming is class
  18. >inheritance and dynamic function dispatching.  The notion of
  19. >object->class->method-table is not necessary for understanding this; it's a
  20. >useful implementation technique for methods that only specialize on one
  21. >argument, but it's not the appropriate way to conceptualize things.  In
  22. >particular, it breaks down completely when the choice of implementation
  23. >technique is based on two parameters (consider output, where the effect is
  24. >dependent on both the type of object being output and the type of output
  25. >destination (ASCII terminal, window, or file)).
  26.  
  27. I hate to open Pandora's box, but since this mailing list is probably
  28. not read by droves of Smalltalk weenies, I may be able to do so without
  29. causing a 2 week mail flood. Wish me luck.
  30.  
  31. I find the CLOS generic function approach to be advantageous to the
  32. SmallTalk and old Flavors message sending approach for everything but
  33. one important case: delegation. Sometimes you want to have an object
  34. that special cases a couple of operations, but sends most of them on
  35. to another object. Neither CALL-NEXT-METHOD nor NO-APPLICABLE-METHOD
  36. is a satisfactory solution to this problem, as each must be used on
  37. a per generic function (or per generic function metaclass) basis and
  38. the delegating object does not know or want to know the complete set
  39. of operations likely to be performed on it. The MOP (as defined in
  40. the AMOP) also cannot solve this problem as the only specializable
  41. arguments to COMPUTE-EFFECTIVE-METHOD are the generic function and
  42. the method combination object. None of the arguments is available.
  43. Only by changing the way that effective methods are computed on a
  44. system-wide basis is there a hope of providing delegation,
  45. and this is likely to be difficult to do and non-portable even
  46. with a standardized MOP.
  47.  
  48. Said more succinctly, the concept of object delegation is foreign to the
  49. generic function paradigm. The former is object centric. The latter
  50. is function centric. The function centric approach is more natural for
  51. Lisp, but the object centric approach seems more natural to me for
  52. systems of distributed objects.
  53.  
  54.