类本身的子类。为什么禁止相互子类化？

Question

我认为这个问题很复杂，但是学习 OWL 为生活、宇宙和一切打开了一个新的视角。我在这里要讲哲学。

我正在尝试实现一个类 C，它是 B 的子类，而 B 又是 C 的子类。只是为了好玩，你知道......

所以很

>>> 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
>>> 

明显，Python 很聪明并且禁止这样做。然而，在 OWL 中可以将两个类定义为相互的子类。问题是：令人难以置信的解释是什么，为什么这在 OWL（不是编程语言）中是允许的，而在编程语言中是不允许的？

Answer 1

Python 不允许这样做，因为没有明智的方法来做到这一点。你可以发明关于如何处理这种情况的任意规则（也许某些语言就是这么做的），但由于这样做没有实际好处，Python 拒绝猜测。由于多种原因，类需要具有稳定的、可预测的方法解析顺序，因此不允许奇怪的、不可预测的或令人惊讶的 MRO。

也就是说，Python 中有一种特殊情况：类型 和对象。 object 是type 的实例，而type 是object 的子类。当然，type也是type的一个实例（因为它是object的子类）。这可能就是 OWL 允许这样做的原因：如果您希望所有东西都是对象并且所有对象都有一个类，那么您需要在某些奇点中启动类/元类层次结构。

Answer 2

Python 中实现的 MRO 方案（自 2.3 起）禁止循环子类化。有效的 MRO 保证满足“局部优先级”和“单调性”。循环子类化会打破单调性。

此问题在标题为“错误方法解析命令”的部分中讨论

Answer 3

这种“脱节”的部分原因是 OWL 描述了一个开放世界本体。除了程序可以操纵本体之外，本体与程序几乎没有任何关系。

尝试将 OWL 概念与编程语言联系起来就像尝试将钢琴家与钢琴奏鸣曲联系起来一样。

奏鸣曲在有人演奏之前并没有真正的具体表现——最好是钢琴家，但不一定。在演奏之前，它只是音符之间的潜在关系，表现为声音。当它被播放时，一些实际的关系将与你（听众）相关。有些与听众无关。

Answer 4

我认为答案是“当你构造 C 类时......它必须创建 B 类的实例......它必须创建 C 类的实例......等等”这永远不会结束。这在大多数语言中都是被禁止的（事实上我不知道其他情况）。
您只能创建一个具有对其他对象的“引用”的对象，该对象最初可以为空。

Answer 5

对于语义推理器，如果 A 是 B 的子类，并且 B 是 A 的子类，则可以认为这些类是等价的。它们并不“相同”，但从推理的角度来看，如果我可以推理一个人是（或不是）A类的成员，我可以推理这个人是（或不是）B类的成员类 A 和 B 在语义上是等价的，这就是您可以用 OWL 表达的内容。

Answer 6

我相信有人可以举出一个有意义的例子。然而，我认为这种限制更容易，而且威力也更大。

例如，假设类 A 包含字段 a 和 b。 C类持有b和c。那么 C 中的事物的视图将是：Aa、Cb、Cc，而 A 中的视图将是：Aa、Ab、Cc

不过，只需将 b 移至公共基类中就更容易理解和实现。