Message12436

It looks like I have to understand this after all. Here are some initial thoughts.

Having read a bit (https://python-history.blogspot.com/2010/06/method-resolution-order.html), (https://en.wikipedia.org/wiki/C3_linearization), Barrett 1996, (https://opendylan.org/documentation/intro-dylan/methods-generic-functions.html), my first question-to-self is why we are using C3 to resolve the MRO of classes defined in Java.

A class defined in Python having Java bases should use C3 at that step, but here we are tripping over a class validly defined in Java. In addressing the merge for com.ibm.mq.jms.MQQueue, we attempt to merge these lists:

[javax.jms.Queue, javax.jms.Destination, java.lang.Object, object]

[com.ibm.msg.client.jms.JmsQueue, com.ibm.msg.client.jms.JmsDestination, com.ibm.msg.client.jms.JmsPropertyContext, com.ibm.msg.client.jms.JmsReadablePropertyContext, java.io.Serializable, java.util.Map, javax.jms.Queue, javax.jms.Destination, java.lang.Object, object]

[com.ibm.mq.jms.MQDestination, com.ibm.jms.JMSDestination, com.ibm.msg.client.jms.admin.JmsJndiDestinationImpl, javax.naming.Referenceable, com.ibm.msg.client.jms.admin.JmsDestinationImpl, com.ibm.msg.client.jms.JmsDestination, com.ibm.msg.client.jms.internal.JmsPropertyContextImpl, com.ibm.msg.client.jms.JmsPropertyContext, com.ibm.msg.client.provider.ProviderPropertyContextCallback, com.ibm.msg.client.jms.internal.JmsReadablePropertyContextImpl, com.ibm.msg.client.jms.JmsReadablePropertyContext, java.io.Serializable, java.util.Map, javax.jms.Destination, java.lang.Object, object]

[javax.jms.Queue, com.ibm.msg.client.jms.JmsQueue, com.ibm.mq.jms.MQDestination]

The last of these is the bases of com.ibm.mq.jms.MQQueue and the first 3 are the MROs of these bases. Each of the list heads is in one of the list tails, and so C3 falls at the first hurdle.

Java allows multiple inheritance from interfaces, but the resolution strategy is not C3. Ordering of bases is (I think) irrelevant, since at most one ancestor can bring an implementation. The exception to this (that I know about) relates to constants. Constants of the same name can have conflicting definitions by inheritance from interfaces. Python would decide which one wins using order: Java would make it illegal to use the ambiguous name (at compile time).

If Java is insensitive to the ordering of bases, complex heterarchies defined in Java will surely turn up a lot of examples that Java has allowed but C3 rejects. Shouldn't we be using Java rules for Java classes?

Also, I really don't see why, if the problem is that the *classes* can't be merged by C3, a solution should be sought in the examination of particular clashing *attributes*. When we find such a clash, it appears we force our MRO to accept a candidate C3 would not, then continue from there. This forcing obviously moves us towards termination, but I don't see the logic of the particular choice.