Re: ECOOP Reaction to CLOS

[Kelley.pa@Xerox.COM]

In dealing with the intractability of the effect of the proposed CLOS
mechanism for multiple inheritance, violation of the "implicit
inheritance - explicit override" rule should be factored out of the
complexity of the linearization algorithm.  Each contribute to the
complexity of the CLOS proposal, but hopefully by distinguishing them
and dealing with each seperately, the total complexity can be reduced.

The CLOS proposed standard explicitly claims in general to obey the
implicit inheritance - explicit override rule, but it does not for
multiple inheritance of slots and methods with the same name.  Instead,
it actually reverses the rule in this case.  Overriding is implicit and
one must explicitly inherit (via qualifiers).  

In as much as implicit inheritance is a sub-conscious assumption of
application programmers, standard CLOS behaves in a counter intuitive
manner.     

(defclass border (object) (width))
(defmethod close (b border) ...)

(defclass window (object) (width))
(defmethod close (w window) ...)

(defclass bordered-window (border window))
(setq b-window (make-instance 'bordered-window))

(close b-window)  ; with the current inheritance algorithm, only closes
the border.  Does not close the window.

The following explores what could happen if the implicit inheritance -
explicit override rule were followed in CLOS.  

(close b-window) would result in both the border and window close
methods getting called because it inherits them implicitly and has not
explicitly overridden them.  

With implicit inheritance a class may have in addition to multiple
methods with the same name that all get called by one call, multiple
occurrences of a slot with the same name that are manipulated in one
operation so b-window would contain two slots named width.

(setf (slot-value b-window width) 0)  

Would set both slots to 0.

A problem is what to do with the results of an operation on a slot name
that refers to two or more slots or on a call that refers to two or more
methods.  Operating on these slots or methods that have not been
overridden could be specified to return a "multiple-inheritance-result"
object containing the multiple results.  

Any code that depended on the results from instances of singly inherited
classes would not work correctly with instances of multiply inherited
classes. (In the example above, any code that depended on the value
returned by the "close" method on an instance of the window class would
not work on an instance of the bordered-window class.)  A blatant error
would usually be generated at run time.  A warning of potential such
behavior at definition time might be a desireable feature.

All the unqualified inherited methods with the same name would still
have to get executed in some order.  However, it would be possible to
simply specify that these operations are executed in a random order. 

 -- kirk