[cedet-eieio] Yet another multiple inheritence problem

[Jan M. <jan...@un...>]

Hi,

I'm back with yet another multiple inheritance problem (too many mixins,
I guess) ;)

My class graph looks like this:

                        eieio-default-superclass
                                   |
               +-------------------+-------------------+
               |                   |                   |
          rudel-state    rudel-impersonator    rudel-delegator
               |                   |                   |
               +-------------------+-------------------+
                                   |
                            rudel-obby-state     e-def-sup
                                   |                |
                  +----------------+                |
                  |                                 |
   rudel-obby-client-connection-state    rudel-obby-document-handler
                  |                                 |
                  +----------------+----------------+
                                   |
                  rudel-obby-client-state-subscribing

[In case the diagram gets messed up:

(defclass rudel-state ()
(defclass rudel-impersonator () 
(defclass rudel-delegator ()
(defclass rudel-obby-state (rudel-state rudel-impersonator
rudel-delegator)
(defclass rudel-obby-client-connection-state (rudel-obby-state)
(defclass rudel-obby-document-handler ()
(defclass rudel-obby-client-state-subscribing
(rudel-obby-client-connection-state rudel-obby-document-handler)

]

The problem appears with an invocation of the generic function
`no-applicable-method'. There is a method installed for
`rudel-delegator' and, of course, for `eieio-default-superclass'. I
expected the method for `rudel-delegator' to be called, since it is on
the most specific class. On second thought, the breadth-first method
resolution order cannot really do that, so the behavior is as expected.
However, I would like a different behavior better.

Despite my current problem, I think the breadth-first search may not be
optimal. A little searching yielded [1] in which the so-called C3
algorithm is described. The points made there seem very logical to me.
So much in fact, that I ported the implementation to Elisp and engaged
in some experiments. As expected, my problem could be solved, were :c3
available as a :method-invocation-order.

In my opinion, it would be very useful to include a :c3 method
resolution order in EIEIO, or even make it the default.

I attached some code to reproduce the original problem, my c3
implementation experiments and a patch that allows :c3 as
a :method-invocation-order (it is not a complete implementation,
though).

What do you think?

Kind regards,
Jan

[1] http://192.220.96.201/dylan/linearization-oopsla96.html