Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!ifistg!rathke@is.informatik.uni-stuttgart.de
From: rathke@is.informatik.uni-stuttgart.de (Christian Rathke)
Newsgroups: comp.lang.clos
Subject: RE: CLOS Private Methods
Message-ID: <11744@ifi.informatik.uni-stuttgart.de>
Date: 26 Jun 91 10:18:26 GMT
Sender: news@ifistg.uucp
Lines: 71
In-reply-to: <1991Jun26.071539.8418@Think.COM>

In article <1991Jun26.071539.8418@Think.COM> barmar@think.com (Barry Margolin) writes:
       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.
       
       This indicates that above methods were misdesigned, or (to give the author
       the benefit of the doubt) they were designed to be used as leaf classes,
       not as mixins.  In order to allow classes to be mixed together, the methods
       have to use (when (next-method-p) (call-next-method ...)) or be implemented
       as :before or :around methods (in which case you have to make sure there is
       a base class with a primary method).
       
... or use a method combination of type PROGN.


       If the mixins are designed and documented properly, you shouldn't need the
       source code to use them.  Unfortunately, there still isn't enough
       experience in the industry in proper design and documentation of OO
       components, so you end up with code like the above.

I think there is a more principle problem with designing and modularizing
functionality (not only) in object-oriented programming.  "Proper design" can try
to but can never meet the requirement of anticipating all possible future uses.
The CLEAN methods of neither HOUSE nor BOAT above were intended to be used in the
HOUSEBOAT or a similar context.

I can think of several possible fixes:

As far as I can remember, LOOPS was using some mechanism to refer to the "fringe"
methods of super-classes.

One could also think of modifying the method combination type (probably more
problems generated than solved)

Finally, programming support for object-oriented systems could support the
inspection (browsers, etc.) and modification of inherited information.
       
       -- 
       Barry Margolin, Thinking Machines Corp.
       
       barmar@think.com
       {uunet,harvard}!think!barmar


-Christian Rathke

==============================================================================
Christian Rathke                            rathke@informatik.uni-stuttgart.de
Institut fuer Informatik
Universitaet Stuttgart
Breitwiesenstrasse 20-22
W-7000 Stuttgart 80                                   Tel.: (+49 711) 7816-436
==============================================================================