Множественное наследование и Оберон

[Geniepro]

Господа, а напомните, плиз, как на Обероне реализуется функциональность, которую даёт множественное наследование (интерфейсов) в других языках...

[ilovb]

В Active Oberon есть DEFINITION.

[kemiisto]

H. Mössenböck. Twin - A Design Pattern for Modeling Multiple Inheritance.
J. Templ. A systematic approach to multiple inheritance implementation.

[Geniepro]

Ага, пасиба, одну статью Темпла на эту тему я уже нашёл ("Оберон против С++" (1995)).

Активный Оберон не хотелось бы трогать...

[Geniepro]

В статье Йозефа Темпла "Оберон против С++" (1995) написано:

Имеет место чёткое различие между созданием подтипов (расширение записи) и созданием подклассов (наследование кода). Наследование кода, включающее в себя множественное и даже динамическое наследование,может быть достигнуто путём программирования в разработчике соответствующего механизма диспетчеризации сообщений (см. ELSE-часть на рис. 3).

Код: [Выделить]

TYPE
  CopyMsg = RECORD (ObjectMsg)
    deep: BOOLEAN;
    cpy: Object
  END;
  DisplayMsg = RECORD (ObjectMsg)
    F: Frame;
    x, y: INTEGER;
  END;

PROCEDURE HandleMyObject (O: Object; VAR M: ObjectMsg);
BEGIN
  IF M IS CopyMsg THEN ...
  ELSIF M IS DisplayMsg THEN ...
  ...
  ELSE Objects.Handle(O,M)
  END
END HandleMyObject;

Честно говоря, не очень наглядный код...

Если я правильно понял, то тут получается что-то противоположное наследованию двух интерфейсов одним классом: тут создаются два отдельных класса, а методы этих двух интерфейсов реализованы в одной процедуре... Это совсем не то, что я ожидал...

[Geniepro]

Шаблон "Близнецы" (Twin pattern) ниасилил, как с этим можно жить?
Выдержка из статьи H. Mössenböck. Twin - A Design Pattern for Modeling Multiple Inheritance.

Although this is considerably more complex than multiple inheritance, it is rare that a class inherits from more than two parent classes.

[vlad]

Шаблон "Близнецы" (Twin pattern) ниасилил, как с этим можно жить?

Тебе чего сделать-то надо? Множественное наследование "в отрыве" никому не надо

[Geniepro]

Вот уж действительно Богатырёв прав: Оберон -- это ассемблер ООП...

[Geniepro]

Шаблон "Близнецы" (Twin pattern) ниасилил, как с этим можно жить?

Тебе чего сделать-то надо? Множественное наследование "в отрыве" никому не надо

Да просто увидеть, как 1 тип данных (класс) получит возможность использования методов нескольких интерфейсов.

Ну, тут у меня может ещё и смешались в голове классы типов Хаскелла -- их я считаю идеальными для этой задачи, так как сам тип данных не обязан ничего знать о классах типов. А вот в шарпе/яве класс должен знать об интерфейсах и реализовать их методы...

[vlad]

Тебе чего сделать-то надо? Множественное наследование "в отрыве" никому не надо

Многое из того, что решается множественным наследованием в традиционных ЯП на обероне может быть выражено через message bus. И не надо воротить этот ужос-ужос из статей, чтобы эмулировать именно множественное наследование само по себе.

[Geniepro]

Многое из того, что решается множественным наследованием в традиционных ЯП на обероне может быть выражено через message bus. И не надо воротить этот ужос-ужос из статей, чтобы эмулировать именно множественное наследование само по себе.

Делать через message bus, если я правильно себе это представляю, означает концентрировать в одной процедуре функциональность логически разных наборов процедур (интерфейсов).
Правильный ли это подход? А как же "разделяй и властвуй"?

[Valery Solovey]

Да просто увидеть, как 1 тип данных (класс) получит возможность использования методов нескольких интерфейсов.

Использовать методы через механизм интерфейсов, которые сам же и реализует? Какой в этом смысл?

[Geniepro]

Да просто увидеть, как 1 тип данных (класс) получит возможность использования методов нескольких интерфейсов.

Использовать методы через механизм интерфейсов, которые сам же и реализует? Какой в этом смысл?

Смысл в том, что бы представлять один и тот же объект как реализующий разные наборы процедур в разных случаях использования. интерфейсный полиморфизм...

Но это в духе сишарпа/явы.
Было бы интереснее (для меня по крайней мере) увидеть, как на обероне имитируются классы типов хаскелла -- сам тип данных ничего не знает о классах типов, и для каждого класса типов реализуется отдельный instance этого типа. А затем экземпляр этого типа данных можно передать туда, где ожидается объект, реализующий интерфейс этого класса типов...

[vlad]

Делать через message bus, если я правильно себе это представляю, означает концентрировать в одной процедуре функциональность логически разных наборов процедур (интерфейсов).

Нет. Message bus позволяет "вызвать" нужный метод нужного интерфейса (из множества) используя ссылку на один объект. Правда при этом остается декларативная проблема - нельзя статически проверить обработает ли данный объект данное сообщение (реализует ли он этот интерфейс). Но такая проверка не всегда и нужна (в случае множественного наследования тоже порой приходится сначала кастнуть к нужному интерфейсу и статически возможность такого каста не проверяется). И никто не говорил, что message bus - это полноценная замена множественному наследованию. Просто оно покрывает часть случаев использования множественного наследования и менее громоздко в реализации, чем эмуляция полноценного множественного наследования (с нормальной декларацией интерфейсов и статическими проверками).

[Valery Solovey]

Было бы интереснее (для меня по крайней мере) увидеть, как на обероне имитируются классы типов хаскелла -- сам тип данных ничего не знает о классах типов, и для каждого класса типов реализуется отдельный instance этого типа. А затем экземпляр этого типа данных можно передать туда, где ожидается объект, реализующий интерфейс этого класса типов...

Что-то я запутался... Несколько раз прочитал, но чётко понять "что кому чего" не смог. Может ссылка есть на этот класс типов? На определение.