🚀 go-pugleaf

    Date: Wed, 26 Jun 1991 03:15 EDT
    From: barmar@think.com (Barry Margolin)

    References <LGM.91Jun25201133@cbnewsc.ATT.COM>, <9106260502.AA11848@kuwait>, <42474@ucbvax.BERKELEY.EDU>
    Reply-To : barmar@think.com
    Subject : Re: CLOS Private Methods

    In article <42474@ucbvax.BERKELEY.EDU> konstan@elmer-fudd.berkeley.edu (Joe Konstan) writes:
    >Re:  Encapsulation and fear of packages
    >
    >I think that the lack of encapsulation problem is more than merely a fear of
    >packages.  With CLOS, there are many cases where a useful functionality is
    >unavailable unless you have (and can modify) the source code to a class and/or
    >the methods which specialize on that class.  For one example ...

    >(defmethod CLEAN ((self HOUSE))
    >  (wash-windows self)
    >  (scrub-floors self))
    >
    >(defmethod CLEAN ((self BOAT))
    >  (scrape-barnacles self))		;; I show my ignorance about boats
    >
    >The default behavior I want for HOUSEBOAT is to do both.  I can't do this by
    >not defining a method, since neither HOUSE not BOAT does a call-next-method
    >and therefore only the first superclass will have its method called.

Here is one possibility:

(defgeneric CLEAN (thing)
  (:method-combination progn))

(defmethod CLEAN progn ((self HOUSE))
  (wash-windows self)
  (scrub-floors self))

(defmethod CLEAN progn ((self BOAT))
  (scrape-barnacles self))		;; I show my ignorance about boats

Note that boats and houses do not have to know about each other.