클래스 자체의 하위 클래스입니다.상호 서브클래싱이 금지되는 이유는 무엇입니까?

StackOverflow https://stackoverflow.com/questions/2223300

  •  19-09-2019
  •  | 
  •  

문제

복잡한 질문인 것 같지만 OWL을 공부하면서 우주와 모든 것에 대한 새로운 관점이 열렸습니다.나는 여기서 철학적으로 갈 것입니다.

나는 C의 하위 클래스인 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
>>>

확실히 파이썬은 똑똑해서 이것을 금지합니다.그러나 OWL에서는 두 클래스를 상호 하위 클래스로 정의하는 것이 가능합니다.질문은 ~이야:이것이 프로그래밍 언어가 아닌 OWL에서는 허용되고 프로그래밍 언어에서는 허용되지 않는 이유에 대한 놀라운 설명은 무엇입니까?

도움이 되었습니까?

해결책

Python에서는 합리적인 방법이 없기 때문에 이를 허용하지 않습니다.그러한 경우를 처리하는 방법에 대해 임의의 규칙을 만들 수 있지만(아마도 일부 언어에서는 그럴 수 있음) 그렇게 해도 실제 이득이 없기 때문에 Python은 추측을 거부합니다.클래스에는 여러 가지 이유로 안정적이고 예측 가능한 방법 해결 순서가 필요하므로 이상하거나 예측할 수 없거나 놀라운 MRO는 허용되지 않습니다.

그러고보니 거기에 ~이다 Python의 특별한 경우: type 그리고 object. object 의 사례이다 type, 그리고 type 의 하위 클래스입니다 object.그리고 물론, type ~이다 또한 인스턴스 type (이것은 하위 클래스이기 때문에 object).이것이 OWL이 이를 허용하는 이유일 수 있습니다.모든 것이 객체가 되고 모든 객체가 클래스를 갖기를 원한다면 어떤 특이점에서 클래스/메타클래스 계층 구조를 시작해야 합니다.

다른 팁

Python (2.3 기준)으로 구현 된 MRO 체계는 주기적 서브 클래싱을 금지합니다. 유효한 MRO는 "지역 우선 순위"와 "단조성"을 만족시킬 수 있습니다. 주기적 서브 클래스는 단조를 깨뜨릴 것이다.

이 문제는 제목의 섹션에서 설명합니다 "잘못된 방법 해결 주문"

이 "분리"의 일부는 올빼미가 열린 세계 온톨로지를 묘사하기 때문입니다. 온톨로지는 프로그램과 관련이 거의 없거나 전혀 관련이 없습니다. 프로그램은 온톨로지를 조작 할 수 있습니다.

올빼미 개념을 프로그래밍 언어와 관련시키는 것은 피아니스트와 피아노 소나타를 연관시키는 것과 같습니다.

소나타는 누군가가 연주 할 때까지 실제로 구체적인 표현을 가지고 있지 않습니다. 이상적으로는 피아니스트이지만 반드시는 아닙니다. 그것이 연주 될 때까지, 그것은 단지입니다 잠재적인 음표 간의 관계는 소리로 나타납니다. 그것이 재생 될 때, 실제 관계 중 일부는 청취자와 관련이 있습니다. 일부는 청취자와 관련이 없습니다.

대답은 "클래스 C를 구성 할 때 ... 클래스 B의 인스턴스를 만들어야합니다. 클래스 C의 인스턴스를 만들어야합니다." 이것은 대부분의 언어로 금지되어 있습니다 (사실 나는 다른 경우를 모른다). 처음에는 null이 될 수있는 다른 객체에 대한 '참조'가있는 객체 만 만들 수 있습니다.

시맨틱 추론 자에게는 A가 B의 서브 클래스이고 B가 A의 서브 클래스 인 경우 클래스는 동등한 것으로 간주 될 수 있습니다. 그것들은 "동일"이 아니지만 추론 관점에서, 개인이 클래스 A의 구성원이라고 추론 할 수 있다면, 개인이 클래스 B의 구성원이거나 그렇지 않은 것을 추론 할 수 있습니다. . 클래스 A와 B는 의미 적으로 동일하며, 이는 부엉이로 표현할 수있는 것입니다.

나는 누군가가 이것이 의미가있는 예를 가지고있을 수 있다고 확신합니다. 그러나이 제한이 더 쉽고 강력하지는 않습니다.

예를 들어, 클래스 A가 필드 A와 b를 보유한다고 가정 해 봅시다. 클래스 C는 B와 C를 보유합니다. C의 사물에 대한 견해는 다음과 같습니다. AA, CB, CC 및 A의 견해는 다음과 같습니다. AA, AB, CC.

그러나 B를 공통 기본 클래스로 옮기는 것만으로는 이해하고 구현하기가 훨씬 쉽습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top