Подкласс класса сам по себе. Почему взаимное наследование запрещено? - PullRequest
4 голосов
/ 08 февраля 2010

Сложный вопрос, я полагаю, но изучение 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 (который не является языком программирования) и запрещено в языках программирования?

Ответы [ 6 ]

9 голосов
/ 08 февраля 2010

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

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

2 голосов
/ 08 февраля 2010

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

Попытка соотнести понятия OWL с языками программирования - это все равно, что попытаться связать сонату пианиста и фортепиано.

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

2 голосов
/ 08 февраля 2010

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

Эта проблема обсуждается в разделе, озаглавленном «Распоряжения о недопустимом методе»

1 голос
/ 08 февраля 2010

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

1 голос
/ 08 февраля 2010

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

0 голосов
/ 08 февраля 2010

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

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

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

...