CPL anxieties

[edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)]

Gabriels "green, animate turtles" diagram is super-simplification of
the example I showed several people at the Boston meeting in Dec 1985; 
Danny had actually seen it earlier that year.  The oversimplification 
was the joining of the superclasses at the second level;  because of that, 
the depth-first **up to join** type algorithms will in fact become breadth 
first on it [which is the desired behaviour!].

A closer approximation to the troubling scenario is below, which has no
super-class hierarchy drawn above the third level.  Then Dick's commentary 
and criticisms apply exactly to it.  That is, any algorithm which tries to 
preserve the property that "inherited methods are  indistinguishable from 
present methods" will have to place at least some of the super-super-classes 
before one of the direct supers, and thus the resulting order will not be 
breadth-first.  

This example may be related to the problem of "shadowing methods", which
hasn't yet been addressed, but which some people feel is important.


(defclass Animate-things (. . . ) ())		  ;has possibly many suprs
(defclass Colored-things (. . . ) ())		  ;has possibly many suprs also
(defclass Turtles (Animate-things) ())
(defclass Green-things (Colored-things) ())
(defclass Green-turtles (Turtles Green-things) ())


		     .
		     .
		     .                      .
	     Animate-things                 . 
	       blush-method  = turn-pink    . 
		 |                          .
		 |	      Colored-things
		 |	        noseup-method = become-haughty
		 |		  |
                /                  \
   Turtles                           Green-things
     noseup-method = pick-up-pen       blush-method = turn-purple
              \                      /
                \                  /
                  \              /
                         |
                         |
                    Green-turtles


I presume everyone can see the conflict which will arise if the two 
direct supers to Green-turtles don't directly follow the class itself.
One way to view this situation is that Green-turtles is a contradictory
class, because it would inherit, say, a blush-method from two distinct
suprs -- from Green-things and from Animate-things.  Another view is
that the present methods of the direct suprs are "more important and
shadow any "higher" up.  A third view is that the user ought to be
able to distinguish such situations in his program in a simple way.

If you are of the first opinion, then a good question to ask yourself
is "Why does the conflict go away when I merge the class Colored-things 
into the class Animate-things?  Should it?"

The basic problem is the rigidity and complexity of the CPL algorithm.  In 
some (unlikely) choices of supers for Animate-things and for Colored-things,
it may be that the CPL will fortuitously be
    (Green-turtles  Turtles  Green-things  .  .  .)
but if so, the user will probably have no way of understanding why.  He
will certainly complain that there is no comprehensible way to control
the CPL algorithm when it produces an ordering with some random super-super
ahead of one of the two direct supers.  No easily-comprehensible way to 
control CPL means essentially no control over inheritance, which means,
again, a "black box of unpredicibility, like Flavors".


-- JonL --

[Regarding the impredicability of Flavors-type inheritance -- I know KDO 
fairly well know, and wouldn't accuse him of shallow understanding.  If he 
had to tweak flavors classes in an unknowing way to get the desired behaviour
out of them, it was because there was no reasonably comprehensible way to
program the desired behaviour.]