Подкласс самого себя.Почему взаимное создание подклассов запрещено?

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

очевидно, что Python умен и запрещает это.Однако в OWL можно определить два класса как взаимные подклассы.Вопрос в том:какое ошеломляющее объяснение, почему это разрешено в OWL (который не является языком программирования) и запрещено в языках программирования?

Это было полезно?

Решение

Python не позволяет этого, потому что нет разумного способа сделать это.Вы можете изобрести произвольные правила о том, как обрабатывать такой случай (и, возможно, некоторые языки так и делают), но поскольку от этого нет никакой реальной выгоды, Python отказывается гадать.Классы должны иметь стабильный, предсказуемый порядок разрешения методов по ряду причин, поэтому странные, непредсказуемые или неожиданные MRO не допускаются.

Тем не менее, там является особый случай в Python: type и object. object является примером type, и type является подклассом object.И конечно, type является также экземпляр type (поскольку это подкласс object).Возможно, поэтому OWL позволяет это:вам нужно создать иерархию классов/метаклассов в некоторой сингулярности, если вы хотите, чтобы все было объектом и все объекты имели класс.

Другие советы

Схема MRO, реализованная в Python (начиная с версии 2.3), запрещает циклическое создание подклассов.Действительные MRO гарантированно удовлетворяют «локальному приоритету» и «монотонности».Циклическое создание подклассов нарушит монотонность.

Этот вопрос обсуждается в разделе под названием «Приказы о разрешении неправильных методов»

Частично это «разрыв» связано с тем, что OWL описывает онтологию открытого мира.Онтология не имеет ничего общего с программой, за исключением того, что программа может манипулировать онтологией.

Попытка связать концепции OWL с языками программирования подобна попытке связать «Пианиста» и «Фортепианную сонату».

Соната на самом деле не имеет конкретного воплощения до тех пор, пока ее не сыграет кто-то — в идеале пианист, но не обязательно.Пока в него не играют, это просто потенциал отношения между нотами, выраженными в виде звуков.Когда его разыгрывают, некоторые реальные отношения будут важны для вас, слушателя.Некоторые из них не будут иметь значения для слушателя.

Я думаю, ответ таков: «Когда вы создаете класс C…он должен создать экземпляр класса B..который должен создать экземпляр класса C...и так далее» Этому никогда не будет конца.Это запрещено в большинстве языков (на самом деле я не знаю другого случая).Вы можете создать объект только со «ссылкой» на другой объект, который изначально может иметь значение null.

Для семантического рассуждения, если A является подклассом B, а B является подклассом A, то классы можно считать эквивалентными.Они не «одинаковые», но с точки зрения рассуждения, если я могу рассуждать, что человек является (или не является) членом класса А, я могу рассуждать, что человек является (или не является) членом класса Б. .Классы A и B семантически эквивалентны, и это то, что вы смогли выразить с помощью OWL.

Я уверен, что кто-то может привести пример, где это имеет смысл.Однако я думаю, что это ограничение проще и не менее мощное.

Например, предположим, что класс A содержит поля a и b.Класс C содержит b и c.Тогда взгляд на вещи из C будет таким:A.a, C.b, C.c и вид из A будет:А.а, А.б, К.в.

Однако гораздо проще понять и реализовать простое перемещение b в общий базовый класс.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top