Непонимание наследования

В квотезы! :)

я же писал, в том же с++ такое не работатет

А зачем вообще так писать?

можно думать это как о виде Dependency Injection: без предварительной настройки среды ничего не запустится, а «отсутствующие» определения считаются магически-подставляемыми. Чтобы не вызывать обширную ненависть у пользователей, магически-подставляемые штуки хорошо предварительно описывать в комментарии.

В том же С++ вообще нет ООП.

А существует какой-нибудь язык с управляемым множественным наследованием? Т.е. чтобы при возникновении коллизий (точное совпадение имени метода, сигнатуры, опций, и чего там еще есть), можно было вбить описание метода разрешения коллизии (@prefer(A) static int doSomething, например)?

С ходу не вспомню, везде вроде бы предопределенный MRO.

Алсо, в Dylan'е приведенный пример работает. Да и почему ему не работать в языке с динамической типизацией, если Bfunc не использует никаких фич B.

Ломающие новости! Питон тоже позволяет выстрелить в ногу!

Просто частая ситуация... Допустим, у нас есть Воин, Маг и Разбойник. На этапе проектирования, их решили реализовать тремя разными классами, наследующимися от Игрока. В ходе жизни игры, может не на первый год, так на второй, геймдизайнеры захотели наделить Воина частью способностей Мага, а Мага - частью способностей Разбойника, а кроме того разрешить Боту контролить все эти классы примерно так же, как их контролирует Пользователь. Менять иерархию классов уже поздно, поэтому нужны какие-то интеллектуальные методы смешивания. Которые как бы все и пишут, но синтаксически это выглядит ужасно. Если в языке был бы управляемый method resolution order, или более обще - управляемый context resolution (для языков, где тип определяется контекстом), всё это можно было бы сделать красиво и относительно безболезненно..

захотели наделить Воина частью способностей Мага, а Мага - частью способностей Разбойника

Тут многое зависит от хорошего дизайна классов.

допустим, на псевдоязыке,

class Warrior: function drawWeapon
class Mage: function castSpell
class Rouge: function stealMoney

теперь у нас есть X, изначально X = new Warrior. Теперь мы хотим X.castSpell. Как должна выглядеть красивая конструкция, которая позволит выполнить X.castSpell?

Вот и у меня те же мысли. Сначала питон нравился и притягивал своей якобы простотой и лаконичностью - но такие моменты делают код нечитаемым совершенно.

Нормального ООП в питоне нет.

class Person {
  var skills
}

class Warrior {
  def init() {
     skills.add(weapon);
  }
}

class Mage {
  def init() {
     skills.add(spell);
  }
}

class Linuxoid {
  def init() {
     skills.add(wepon,spell,fat);
  }
}

еще адепты ООП пейсали: «предпочитайте композицию наследованию», тогда не понадобится всякое уг типа множественного наследования.

в твоем исполнении скиллы - не методы, к сожалению. Или ты имеешь в виду паттерн-стратегию?

дело в том, что в языке уже есть свои методы. Зачем использовать вместо них стратегии?

в результате у тебя получится то же управляемое множественное наследование, где var skills - это таблица виртуальных функций, не?

вот я и предлагаю сделать управляемое множественное наследование частью языка, чтобы не надо было городить свои эмуляции, так же как виртуальные функции уже встроены в язык

в твоем исполнении скиллы - не методы, к сожалению

в моем понимании скилл вырожденный в метод не подойдет даже для тетриса, с другой стороны в некоторых ЯП есть ссылки на функции, в яве можно использовать функционально-подобный интерфейс. Т.е. вариантов уйма.

в результате у тебя получится то же управляемое множественное наследование, где var skills - это таблица виртуальных функций, не?

не, ее содержимое не наследуется, наследуется только «интерфес» от Person

вот я и предлагаю сделать управляемое множественное наследование частью языка

сам предположил, сам решил что тебя поддержали, маладец ©

ок, что будешь делать, когда нужно будет устроить наследование скиллов? Например, чтобы у FireWarrior скилл weapon фигачил огнем =)

Динамика головного мозга. Забей.

Абстрактные классы WeaponUser, MagicUser, ThieveryUser?

О, БДСМщики подтянулись :)

перестану принимать такую дурь, понимаешь те каверзы что ты мне пытаешься строить проистекают не из жажды множественного наследования, а из косяков проектирования интерфейсов.

я предлагаю не делать глупостей)
class C(A,B):

Ню-ню... С каких пор множественное наследование - это не делать глупостей? :D

само по себе множественное наследование - не плохо)

само по себе множественное наследование - не плохо)

Похоже, что именно потому, что ты не понимаешь наследование, тебе кажется, что множественное наследование - хорошая идея. Почитай про проблемы с ним и почему множественное наследование - очень плохая идея.

где почитать? Страуструп об этом не пишет))

Потому что в Питоне нет интерфейсов.

гонишь косой (чёрт, как двусмысленно получилось)

class SomeInterface(object):
    def some_method(self):
        raise NotImplementedError("implement or die")

где почитать?

Тебя в гуле забанили?

даже не зная питона, можно понять что метод A.__init__ получает объект self, у которого есть метод Bfunc, который благополучно вызывается. как по мне, то все максимально понятно просто и логично.

И да, self.Bfunc() это просто getattr(self, «Bfunc»)() и никакой магии

Потому что в Питоне нет интерфейсов.

В питоне их вроде как нет, но их можно сделать средствами питона, как например сделали Zope.interface

в гугле пишут и о том как это клево) так что ссылочку в студию. И чтоб не сопливый мальчик рассуждал!

в гугле пишут и о том как это клево

А голова тебе дана на что? Почитал одних, почитал других, включил голову и все понял.

И чтоб не сопливый мальчик рассуждал

И это пишет человек, не понимающий «наследования»? Ню-ню.