Hi Jan,
I was hoping to better understand what's going on with your patch before
responding, but that hasn't happened yet, so I figured I'd just respond.
I don't know anything about c3, but providing additional method
invocation orders sounds nifty to me.
An alternative possible solution if you don't get c3 "complete" as you
like it is that we could make eieio-default-superclass special in that
it always shows up last on any invocation order. In that way, you could
sort your own classes to avoid problems without worrying about the
default superclass.
Eric
Jan Moringen wrote:
> 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
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cedet-eieio mailing list
> cedet-eieio@...
> https://lists.sourceforge.net/lists/listinfo/cedet-eieio
|