Re: ECOOP Reaction to CLOS

[kempf%hplabsz@hplabs.HP.COM]

In <870818-153317-1383@Xerox> kirk writes:

>At any rate, presenting the effects of the proposed inheritance
>algorithm for CLOS would be more understandable if in conjunction with
>presenting the class ordering algorithm, violations of the "implicit
>inheritance - explicit override" rule are clearly marked as such.

Yes, the description in Part 1 of the spec should contain proper
documentation of how slot and class options are default inherited.

In <870818200622.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Moon writes:

> Some comments on characterizing the class precedence list algorithm.
> In my comments I will refer to this set of classes (slots omitted):

> (defclass a (b c w))            w   x  w   y w  x
> (defclass aa (b c d w))          \ /    \ /   \/
> (defclass b (w x))                b      c    d   w
> (defclass c (w y))                 \     |   /   /
> (defclass d (w x))                   \   | /   /
> (defclass w ())                        \ |/  /
> (defclass x ())                          aa
> (defclass y ())

The class a seems to be missing from the diagram, but I'll refrain
from trying to include it, since the result is more confusing that
enlightening.

> We've seen these classes before.  By the rules in 87-002,
> the CPL of a is (a b c w y x) and of aa is (aa b c d w x y).

>     Date: Thu, 9 Jul 87 13:24:38 pdt
>     From: Jim Kempf <kempf%hplabsz@hplabs.HP.COM>

>     The inheritance graph is searched depth first, left to
>     right, up to joins. Superclasses at joins are placed
>     in the class precedence list at the last occurance,
>     rather than the first, since such superclasses are
>     usually more general than their subclasses, and classes
>     at the end of the class precedence list should be more
>     general than those at the beginning. The qualitative
>     effect is to achieve a linearization of the inheritance
>     graph, with more specialized classes at the head of
>     the class precedence list and more general classes at
>     the tail, keeping together groups of classes which occur
>     together in the inheritance graph.

> I like this informal way of explaining it, except that I never figured
> out precisely what "up to joins" means, and depending on the
> interpretation of that phrase, this explanation could be incorrect.
> When the depth first walk of the graph for aa above encounters w above
> c, that's a join.  If it goes on to y, I don't think y is a join,
> nevertheless y is not next in the CPL, x is.

w is, indeed, a join class, since there is more than one line
of inheritance coming out of it. The definition of a join I had in
mind is a class which contributes two or more subclasses to the
CPL calculation. y is not a join, because there is only one line of 
inheritance coming from it (namely y->c->aa). x is also a join, because
there are two lines of inheritance coming from it (namely x->b->aa
and x->d->aa). If we follow the explanation, then, after including
w, we use the local precedence ordering to select x as the next
class to include. In this case, the local precedence ordering takes
priority over other rules and x is included. y is then included after
x.

So a more accurate statement would be:

     Define a join class as a superclass which contributes
     two or more subclasses to a CPL calculation. Define
     the base class as the class for which the CPL calculation
     is being made. To calculate the CPL, the inheritance graph 
     is searched depth first, left to right, up to joins, starting
     with the base class. Join superclasses are placed in the class 
     precedence list at the last occurance, rather than the first, 
     since such superclasses are usually more general than their 
     subclasses (from the base class's point of view), 
     and classes at the end of the class precedence list should be more
     general than those at the beginning. After a join class has
     been inserted, the local precedence ordering for the join
     class is used to start the left to right search again above
     the join. The qualitative effect is to achieve a linearization 
     of the inheritance graph, with more specialized classes at the head of
     the class precedence list and more general classes at
     the tail, keeping together groups of classes which occur
     together in the inheritance graph (i.e. maintaining local
     precedence).

This a a bit more complicated than the original, but more accurate,
I think. Some words about failures to linearize and an example would
also be helpful.