[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: navajo!common-lisp-object-system%SAIL.STANFORD.EDU@navajo.stanford.edu
- Subject: CPL anxieties
- From: firstname.lastname@example.org (Jon L White)
- Date: Sun, 1 Feb 87 22:40:28 PST
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
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) ())
blush-method = turn-pink .
| noseup-method = become-haughty
noseup-method = pick-up-pen blush-method = turn-purple
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.]