home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / object / 3398 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  1.8 KB
  1. Path: sparky!uunet!caen!sdd.hp.com!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.object
  4. Subject: Re: Object-Oriented Methodologies - Class Specifications
  5. Date: 3 Sep 1992 03:18:01 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 27
  8. Message-ID: <184059INNo85@early-bird.think.com>
  9. References: <BtyJK8.GFH@rice.edu> <j1kn6ll.objsys@netcom.com> <j8knsmd.objsys@netcom.com>
  10. NNTP-Posting-Host: gandalf.think.com
  11.  
  12. In article <j8knsmd.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
  13. >But the lack of default protection means no multiple-implementations per
  14. >type; a severe restriction that I doubt even CLOS' intercessory protocols
  15. >can overcome.  Am I wrong here?  Can CLOS provide for the separation of
  16. >types and classes (or any kind of multiple implementations per type)?
  17.  
  18. While CLOS permits unrestricted access to slots (using SLOT-VALUE and
  19. WITH-SLOTS), it certainly doesn't force it, and it's generally considered
  20. bad style for non-methods to do so.  For large scale protection, the
  21. package mechanism is recommended; among related classes within a package,
  22. abstinence is the safest way.
  23.  
  24. CLOS makes it easy to define accessor methods for slots.  Such methods are
  25. indistinguishable from ordinary methods, and can be overridden using
  26. DEFMETHOD in subclasses.  WITH-ACCESSORS is provided as a convenience, so
  27. that you can pretend you're accessing these slots as variables, but you're
  28. still using the OO virtual function mechanism.
  29.  
  30. So long as all functions outside the class implementation make use of the
  31. functional interface to slots, the separation of interface specification
  32. and implementation can be maintained.
  33.  
  34. -- 
  35. Barry Margolin
  36. System Manager, Thinking Machines Corp.
  37.  
  38. barmar@think.com          {uunet,harvard}!think!barmar
  39.