[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CPL anxieties
- To: navajo!Bobrow.pa%Xerox.COM@navajo.stanford.edu
- Subject: CPL anxieties
- From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
- Date: Mon, 2 Feb 87 21:55:47 PST
- Cc: navajo!common-lisp-object-system%SAIL.STANFORD.EDU@navajo.stanford.edu
- In-reply-to: Danny Bobrow's message of 2 Feb 87 18:34 PST
Re: If the currently proposed algorithm is used, you will not be able to see
the difference between merging turtle and animate-thing, and/or merging
gren and colored things. . . .
The "anxiety" followed from merging Colored-things and Animate-things,
rather than either of those with their direct inferiors. When they are
merged (and they have no similar methods so it would be a disjoint
merger), then the "up to join" nature of the pre-order treewalk forces
a semi-breadth-first ordering. Which is what the original source of
this example was trying to achieve.
Re . . . The order proposed puts both turtle and
animate before both green and colored, so the latter two will have no
effect wrt the two methods of concern. I claim this is correct.
This is simply the depth-first order. While it enforces *some* ordering
on the problem, there is no reason in the topology of the inheritance
graph to believe that one ordering is preferable to another. In such
circumstances, either there are some methods which would be inherited from
essentially *incomparable* classes, or there are no such methods. In the
latter case, it is a "moot" point, but in the former, shouldn't an error
of some sort be signalled? or shouldn't there be some way for the user
to specify more exactly what he wants?
The anxieties, then, can be summarized as
1) defining a "mix in" subclass forces the programmer to specify an order
among the direct suprs; but this ordering may have no relation whatsoever
to the application problem, and it will probably determine all the
method inheritance choices.
2) merging/spliting a class "way up" in the inheritance graph can override
what methods the new class has; but the programmer wanted to be able to
say something (anything?) which would insure the selection of the correct
blush and pen-up methods.
Maybe there should be an "unordered" defclass, for which the CPL is built
exactly like in the "ordered" case, but for which the error signalling
conditions might be more stringent.
-- JonL --