home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / scheme / 2043 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  1.8 KB
  1. Path: sparky!uunet!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.lang.scheme
  4. Subject: Re: message passing vs. generic functions
  5. Date: 18 Aug 1992 04:34:46 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 29
  8. Message-ID: <16pul6INNjfq@early-bird.think.com>
  9. References: <9208171954.AA05736@cambridge.apple.com>
  10. NNTP-Posting-Host: gandalf.think.com
  11.  
  12. In article <9208171954.AA05736@cambridge.apple.com> bill@cambridge.apple.COM ("Bill St. Clair") writes:
  13. >I find the CLOS generic function approach to be advantageous to the
  14. >SmallTalk and old Flavors message sending approach for everything but
  15. >one important case: delegation. Sometimes you want to have an object
  16. >that special cases a couple of operations, but sends most of them on
  17. >to another object.
  18.  
  19. This is true.  However, in my experience, automatic delegation like this is
  20. a dangerous practice, and perhaps it shouldn't be facilitated.
  21.  
  22. The problem is that new operations may be added without the knowledge of
  23. the designer of the delegating class.  Perhaps this new operation should be
  24. special cased, but since the class hasn't been updated, it will just pass
  25. it on naively.
  26.  
  27. The Symbolics Genera stream system makes extensive use of such classes, and
  28. it's pretty big mess.
  29.  
  30. If you have a fixed list of operations on a set of classes (as languages
  31. like C++ force you to do) then you don't have the problem of unexpected
  32. operations being added.  But then you don't need to implement delegating
  33. classes by specifying just the special-cases; since the list of normal
  34. cases is available you can define all the delegating operations explicitly
  35. (yes, it's tedious, but you can define a macro to automate it).
  36. -- 
  37. Barry Margolin
  38. System Manager, Thinking Machines Corp.
  39.  
  40. barmar@think.com          {uunet,harvard}!think!barmar
  41.