🚀 go-pugleaf

I'm not sure I made my houseboat problem clear enough in my first posting.
I've seen three postings and some E-mail suggesting either designing the CLEAN
methods to call-next-method (when one is available) or designing CLEAN as a
generic function with method-combination type progn.  This is why I feel that
neither of these is an acceptable solution:

1.	First and foremost, these require that HOUSE and BOAT be assured that
no superclass of theirs ever has a CLEAN method defined.  In fact, I might
very well have defined HOUSE as a subclass of BUILDING and RESIDENCE where
BUILDING has a CLEAN method defined on it which should NOT be used by HOUSE.
As a result, HOUSE's CLEAN cannot (call-next-method) as this will call in the
janitors to clean the BUILDING.  Further, CLEAN cannot use method-combination
type progn since I may have defined BOAT as a subclass of SEA-VESSEL and
some other class where I want to inherit CLEAN using standard method
combination.

2.	Since I am not provided with the source code, I consider it
unreasonable to implement any solution (such as the progn solution) that
requires changing the methods themselves.

Here is what I would consider an adequate solution (or at least a good start):

1.	Let each method have its own method-combination type used to determine
how to interpret call-next-method among its inherited methods (i.e., the
superclasses).

2.	In this case, the method-combination type for HOUSEBOAT could be
progn, but the method-combination types for HOUSE and for BOAT could be
completely different and should not matter.  What matters is that I, as the
creator of the HOUSEBOAT class, can decide that I want to do both the HOUSE
and BOAT operations for CLEAN.

3.	This is clearly harder to optimize and needs to be better defined with
respect to the execution order when :around, :before, and :after methods are
added in, but I think it is workable.

I'm not disputing the claim that a complete system can be designed well so
these problems do not arise.  I don't think this is adequate, however, since
designing a system well in CLOS is hard, and most of the code we would like to
borrow from others will not have been designed well.  As a result, the
language must support techniques for getting the most out of existing classes
and methods without modifying their source code.

Joe Konstan
konstan@cs.berkeley.edu