6

複雑な質問だと思いますが、OWLを研究することで、生きること、宇宙、そしてすべてに新しい視点が開かれました。私はここで哲学的に行きます。

私はBのサブクラスであるクラスCを達成しようとしています。これは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では、2つのクラスを相互のサブクラスとして定義することができます。問題は、これがOWL（プログラミング言語ではない）で許可され、プログラミング言語で許可されない理由について、気が遠くなるような説明は何ですか？

4

6 に答える 6

10

Pythonはそれを行うための賢明な方法がないため、それを許可していません。このような場合の処理​​方法について任意のルールを考案することもできますが（おそらく一部の言語ではそうなります）、そうすることで実際に利益が得られないため、Pythonは推測を拒否します。クラスには、さまざまな理由から、安定した予測可能なメソッド解決順序が必要であるため、奇妙な、予測できない、または驚くべきMROは許可されません。

そうは言っても、Pythonにはtype特別なケースがあります：とobject。objectはのインスタンスでありtype、typeはのサブクラスですobject。そしてもちろん、（のサブクラスであるため）のインスタンスでtypeもあります。これがOWLが許可する理由かもしれません。すべてをオブジェクトにし、すべてのオブジェクトにクラスを持たせたい場合は、クラス/メタクラス階層をいくつかの特異点で開始する必要があります。typeobject

于 2010-02-08T17:03:21.703 に答える
2

Pythonで実装されたMROスキーム（2.3以降）は、循環サブクラス化を禁止しています。有効なMROは、「ローカル優先順位」と「単調性」を満たすことが保証されています。周期的なサブクラス化は単調性を壊します。

この問題については、「不正な方法の解決順序」というタイトルのセクションで説明しています。

于 2010-02-08T17:08:18.357 に答える
2

この「切断」の一部は、OWLがオープンワールドオントロジーを記述しているためです。オントロジーは、プログラムがオントロジーを操作できることを除いて、プログラムとはほとんどまたはまったく関係がありません。

OWLの概念をプログラミング言語に関連付けようとするのは、ピアニストとピアノソナタを関連付けようとするようなものです。

ソナタは、誰かが演奏するまで具体的な表現はありません。理想的にはピアニストですが、必ずしもそうとは限りません。それが演奏されるまで、それは音として現れる音符間の潜在的な関係にすぎません。それが再生されているとき、実際の関係のいくつかはあなた、リスナーに関連します。リスナーに関係のないものもあります。

于 2010-02-08T18:10:09.183 に答える
1

答えは「クラスCを構築するとき...クラスBのインスタンスを作成する必要があります..クラスCのインスタンスを作成する必要があります...など」と思います。これは決して終わりません。これはほとんどの言語で禁止されています（実際、私は他のケースを知りません）。最初はnullになる可能性のある他のオブジェクトへの「参照」を持つオブジェクトのみを作成できます。

于 2010-02-08T17:01:30.117 に答える
1

セマンティック推論の場合、AがBのサブクラスであり、BがAのサブクラスである場合、クラスは同等であると見なすことができます。それらは「同じ」ではありませんが、推論の観点から、個人がクラスAのメンバーである（またはそうでない）と推論できる場合、その個人がクラスBのメンバーである（またはそうでない）と推論できます。 。クラスAとBは意味的に同等であり、OWLで表現できたものです。

于 2010-02-08T20:56:20.713 に答える
0

誰かがこれが理にかなっている例を思いつくことができると確信しています。ただし、この制限はより簡単で、それほど強力ではないと思います。

たとえば、クラスAがフィールドaとbを保持しているとします。クラスCはbとcを保持します。その場合、CからのビューはAa、Cb、Ccになり、AからのビューはAa、Ab、Ccになります。

ただし、bを共通の基本クラスに移動するだけで、理解と実装がはるかに簡単になります。

于 2010-02-08T17:05:51.280 に答える