Subclass of the class. Why is mutual subclassing prohibited?

Question

A difficult question, I suppose, but learning OWL has opened up a new perspective on life, the universe, and all that. I will philosophize here.

I'm trying to reach class C, which is a subclass of B, which in turn is a subclass of C. Just for fun, you know ...

So here

>>> class A(object): pass ... >>> class B(A): pass ... >>> class C(B): pass ... >>> B.__bases__ (<class '__main__.A'>,) >>> B.__bases__ = (C,) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: a __bases__ item causes an inheritance cycle >>> 

it is clear that python is smart and forbids it. However, in OWL, two classes can be defined as mutual subclasses. The question is, what a breathtaking explanation, why is this allowed in OWL (which is not a programming language) and not allowed in programming languages?

Answer 1

Python does not allow this because there is no sensible way to do this. You can invent arbitrary rules on how to handle this case (and possibly some languages), but since there is no real gain in this, Python refuses to guess. Classes must have a stable, predictable method resolution order for a number of reasons, and therefore strange, unpredictable, or unexpected MROs are not allowed.

However, in Python there is a special case: type and object . object is an instance of type , and type is a subclass of object . And of course, type also an instance of type (since it is a subclass of object ). Perhaps this is why OWL allows this: you need to run the hierarchy of classes / metaclasses in some sort of singularity if you want everything to be an object and all objects that have a class.

Answer 2

The MRO scheme implemented in Python (since version 2.3) prohibits a circular subclass. A valid MRO is guaranteed to satisfy "local priority" and "monotony." Cyclical subclassing breaks monotony.

This issue is discussed in the section entitled Orders for failed method processing.

Answer 3

Part of this “disconnect” is that OWL describes the open world ontology. An ontology has little or nothing to do with a program other than a program that can manipulate an ontology.

Trying to connect OWL concepts with programming languages ​​is like trying to connect a pianist and a piano sonata.

The sonata really does not have a specific manifestation until someone plays it - ideally a pianist, but not necessary. Until it is played, it is simply a potential relationship between notes manifested as sounds. When it is reproduced, some of the actual relationships will be relevant to you, the listener. Some of them will not be relevant to the listener.

Answer 4

I think the answer is: "When you build class C ... it should create an instance of class B .. that should create an instance of class C ... etc." It will never end. This is forbidden in most languages ​​(in fact, I do not know another case). You can create an object with a "link" to another object, which may be initially null.

Answer 5

For a semantic argument, if A is a subclass of B and B is a subclass of A, then the classes can be considered equivalent. They are not “the same,” but in terms of reasoning, if I can reason that a person is (or is not) a member of class A, I can reason that a person is (or is not) a member of class B. Classes A and B are semantically equivalent, which you could express using OWL.

Answer 6

I'm sure someone can come up with an example where this makes sense. However, I think this limitation is simpler and no less powerful.

For example, let class A contain fields a and b. Class C has values ​​b and c. Then the view of things from C will be: Aa, Cb, Cc, and the view from A will be: Aa, Ab, Cc

Simply moving b to a common base class is much easier to understand and implement.