Re: ECOOP Reaction to CLOS

[Jim Kempf <kempf%hplabsz@hplabs.HP.COM>]

>I want to make clear what it is I said about the CPL computation: I stated
>that the effect of the CPL algorithm was difficult to understand, not that
>the algorithm is difficult to understand. The difference between the two
>is that an algorithm can be easy to grasp while a characterization of it
>suitable for a programmer to understand is not available.  In contrast,
>the algorithm for computing the strongly connected components of a graph
>is easy to understand as an algorithm, and it is easy to understand what
>it does because the definition of a strongly connected component is easy
>to understand.  The CPL is understood to be a total ordering on a class
>and its superclasses, but the only characteriztion of it that I know of is
>that the CPL is the total ordering computed by the algorithm.  That
>algorithm is understandable at the operational level, but there is no easy
>characterization of it.

I think what most programmers want is a two sentence explanation of how
inheritance works in CLOS. The equivalent for Smalltalk is:

	Child classes get all the methods and all the slots of
        their parents. Any methods defined with the same name
        as the parent defined in the child override the parent's
        method.

I propose this for CLOS:

	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.

Well, that's three sentences, but I think most people won't mind.

A more detailed explantion should go into what can go wrong. The
Ducournau and Habib paper discusses this in a more formal way.
The essense is that if two or more subclasses share two
or more join superclasses, then the algorithm can fail. 
In such cases, the two join superclasses are two alternative end 
elements for the sublist CPL containing the subclasses, so there
is no unique linearization. Scherlis's comments about programmer
hooks at the Palo Alto meeting might be appropriate here, since
the programmer could choose which join superclass is more
general, but I think the appropriate place to put in these hooks
is the metaobject protocol, and not something like prompting the
programmer.

>Intellectual honesty compels me to point out things like this when
>I address an audience. I suppose it annoys people when I do that,
>but maybe we should give some thought to designing a language such that
>there are few oppurtunities for ``Gabriel's inevitable critique.''

I have no problem with such critiques, however, I think at some point
we need to iterate to a design which we all feel comfortable with,
and which application developers can use. My impression of the 
inheritance algorithm is that it refines and solidifies current practice
which is *precisely* what a standard should do. Whether or not it
is the ultimate in linguistic software reuse mechanisms is another 
question. I don't think it is, but until I know the answer, have
tested it with a couple of applications, and have discussed it extensively
with other people, I'm sure not going to recommend that it be made a
standard.


		Jim Kempf	kempf@hplabs.hp.com