Oberon space
General Category => Общий раздел => Тема начата: Geniepro от Сентябрь 06, 2012, 04:54:16 pm
-
Господа, а напомните, плиз, как на Обероне реализуется функциональность, которую даёт множественное наследование (интерфейсов) в других языках...
-
В Active Oberon есть DEFINITION.
-
H. Mössenböck. Twin - A Design Pattern for Modeling Multiple Inheritance.
J. Templ. A systematic approach to multiple inheritance implementation.
-
Ага, пасиба, одну статью Темпла на эту тему я уже нашёл ("Оберон против С++" (http://oberon2005.oberoncore.ru/paper/templ.pdf) (1995)).
Активный Оберон не хотелось бы трогать...
-
В статье Йозефа Темпла "Оберон против С++" (http://oberon2005.oberoncore.ru/paper/templ.pdf) (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;
Честно говоря, не очень наглядный код...
Если я правильно понял, то тут получается что-то противоположное наследованию двух интерфейсов одним классом: тут создаются два отдельных класса, а методы этих двух интерфейсов реализованы в одной процедуре... Это совсем не то, что я ожидал...
-
Шаблон "Близнецы" (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.
-
Шаблон "Близнецы" (Twin pattern) ниасилил, как с этим можно жить?
Тебе чего сделать-то надо? :) Множественное наследование "в отрыве" никому не надо :)
-
Вот уж действительно Богатырёв прав: Оберон -- это ассемблер ООП...
-
Шаблон "Близнецы" (Twin pattern) ниасилил, как с этим можно жить?
Тебе чего сделать-то надо? :) Множественное наследование "в отрыве" никому не надо :)
Да просто увидеть, как 1 тип данных (класс) получит возможность использования методов нескольких интерфейсов.
Ну, тут у меня может ещё и смешались в голове классы типов Хаскелла -- их я считаю идеальными для этой задачи, так как сам тип данных не обязан ничего знать о классах типов. А вот в шарпе/яве класс должен знать об интерфейсах и реализовать их методы...
-
Тебе чего сделать-то надо? :) Множественное наследование "в отрыве" никому не надо :)
Многое из того, что решается множественным наследованием в традиционных ЯП на обероне может быть выражено через message bus. И не надо воротить этот ужос-ужос из статей, чтобы эмулировать именно множественное наследование само по себе.
-
Многое из того, что решается множественным наследованием в традиционных ЯП на обероне может быть выражено через message bus. И не надо воротить этот ужос-ужос из статей, чтобы эмулировать именно множественное наследование само по себе.
Делать через message bus, если я правильно себе это представляю, означает концентрировать в одной процедуре функциональность логически разных наборов процедур (интерфейсов).
Правильный ли это подход? А как же "разделяй и властвуй"?
-
Да просто увидеть, как 1 тип данных (класс) получит возможность использования методов нескольких интерфейсов.
Использовать методы через механизм интерфейсов, которые сам же и реализует? Какой в этом смысл?
-
Да просто увидеть, как 1 тип данных (класс) получит возможность использования методов нескольких интерфейсов.
Использовать методы через механизм интерфейсов, которые сам же и реализует? Какой в этом смысл?
Смысл в том, что бы представлять один и тот же объект как реализующий разные наборы процедур в разных случаях использования. интерфейсный полиморфизм...
Но это в духе сишарпа/явы.
Было бы интереснее (для меня по крайней мере) увидеть, как на обероне имитируются классы типов хаскелла -- сам тип данных ничего не знает о классах типов, и для каждого класса типов реализуется отдельный instance этого типа. А затем экземпляр этого типа данных можно передать туда, где ожидается объект, реализующий интерфейс этого класса типов...
-
Делать через message bus, если я правильно себе это представляю, означает концентрировать в одной процедуре функциональность логически разных наборов процедур (интерфейсов).
Нет. Message bus позволяет "вызвать" нужный метод нужного интерфейса (из множества) используя ссылку на один объект. Правда при этом остается декларативная проблема - нельзя статически проверить обработает ли данный объект данное сообщение (реализует ли он этот интерфейс). Но такая проверка не всегда и нужна (в случае множественного наследования тоже порой приходится сначала кастнуть к нужному интерфейсу и статически возможность такого каста не проверяется). И никто не говорил, что message bus - это полноценная замена множественному наследованию. Просто оно покрывает часть случаев использования множественного наследования и менее громоздко в реализации, чем эмуляция полноценного множественного наследования (с нормальной декларацией интерфейсов и статическими проверками).
-
Было бы интереснее (для меня по крайней мере) увидеть, как на обероне имитируются классы типов хаскелла -- сам тип данных ничего не знает о классах типов, и для каждого класса типов реализуется отдельный instance этого типа. А затем экземпляр этого типа данных можно передать туда, где ожидается объект, реализующий интерфейс этого класса типов...
Что-то я запутался... Несколько раз прочитал, но чётко понять "что кому чего" не смог. Может ссылка есть на этот класс типов? На определение.
-
Было свежее обсуждение:
http://forum.oberoncore.ru/viewtopic.php?p=74239#p74239
-
Что-то я запутался... Несколько раз прочитал, но чётко понять "что кому чего" не смог. Может ссылка есть на этот класс типов? На определение.
"4.1 Обзор типов и классов" (http://www.haskell.ru/decls.html)
"2 Ad-hoc полиморфизм в языке Haskell" (http://fprog.ru/2009/issue3/roman-dushkin-haskell-polymorphism/)
http://www.rsdn.ru/article/haskell/haskell_part1.xml#ERAAG
Сравнение с другими языками. Классы, используемые в Haskell, похожи на классы в других объектно-ориентированных языках, таких как C++ и Java. Однако существуют некоторые важные отличия:
- Haskell отделяет определение типа от определения методов, связанных с этим типом. Класс в C++ или Java обычно определяет и структуру данных (переменные – члены класса) и функции, ассоциированные с этой структурой (методы). В Haskell эти определения даются раздельно.
- Метод класса, определённый в классе Haskell, соответствует виртуальной функции в классе языка C++. Каждое воплощение класса обеспечивает своё собственное определение для каждого метода, умолчания в классе соответствуют реализации по умолчанию виртуальной функции в базовом классе C++.
- Классы Haskell в грубом приближении похожи на интерфейсы в Java. Как и объявления интерфейсов, объявления классов в Haskell задают протокол использования объектов, а не определение собственно объекта.
- Haskell не поддерживает перегрузку в стиле C++, при которой функции с различными типами разделяют общее имя.
- Для типов объектов в Haskell нет неявного приведения; отсутствует универсальный базовый класс, вроде Object, к которому можно приводить значения.
- C++ и Java присоединяют идентифицирующую информацию (такую, как таблица виртуальных функций) к представлению объекта во время исполнения. В Haskell такая информация присоединяется к значениям логически, а не физически, через систему типов.
- В систему классов Haskell не встроен контроль доступа (такой, как метки public или private в определении класса). Вместо этого для сокрытия или раскрытия компонентов следует пользоваться системой модулей.
-
Было бы интереснее (для меня по крайней мере) увидеть, как на обероне имитируются классы типов хаскелла -- сам тип данных ничего не знает о классах типов, и для каждого класса типов реализуется отдельный instance этого типа. А затем экземпляр этого типа данных можно передать туда, где ожидается объект, реализующий интерфейс этого класса типов...
Что-то я запутался... Несколько раз прочитал, но чётко понять "что кому чего" не смог. Может ссылка есть на этот класс типов? На определение.
Эти class types очень похожи на то что есть в Go. Собственно обсуждалось уже: http://oberspace.dyndns.org/index.php/topic,224.msg5085.html#msg5085
-
Если я правильно понял
TYPE
A = RECORD
a1 : PROCEDURE();
a2 : PROCEDURE();
a3 : PROCEDURE();
a4 : PROCEDURE();
END;
X = RECORD END;
X1 = RECORD(X)
x1 : PROCEDURE();
x2 : PROCEDURE();
END;
...
a := NewA();
x := NewX1(a);
(* используем x с его интерфейсом где нам надо *)
-
Если я правильно понял
TYPE
A = RECORD
a1 : PROCEDURE();
a2 : PROCEDURE();
a3 : PROCEDURE();
a4 : PROCEDURE();
END;
X = RECORD END;
X1 = RECORD(X)
x1 : PROCEDURE();
x2 : PROCEDURE();
END;
...
a := NewA();
x := NewX1(a);
(* используем x с его интерфейсом где нам надо *)
Тут не приведены реализации процедур NewA() и NewX1(a), в результате непонятно, зачем нужет тип A...
-
NewA и NewX1 - это конструкторы. Тип A - это исходный объект (методы я не стал выписывать, а просто добавил их внутрь записи). X - это интерфейсы для доступа к A (X1, X2 и т.д.).
-
Кстати, Лаптев на RSDN сейчас жгёт напалмом (по части юмора) про множественное наследование:
http://rsdn.ru/forum/philosophy/4875187.aspx
-
NewA и NewX1 - это конструкторы. Тип A - это исходный объект (методы я не стал выписывать, а просто добавил их внутрь записи). X - это интерфейсы для доступа к A (X1, X2 и т.д.).
Я понял, что это конструкторы, но хотелось бы увидеть, что именно конструктор NewX1 делает с переданной ему записью a...
-
Да ничего особенного не делает...
X1 - это воплощение конструкции
instance Logic A where
...NewX1(a) - это соединение данных с интерфейсом, через который программа умеет обращаться к данным.
Наличие логики в A под вопросом, а вот в X1 она точно будет. Что конкретно NewX1 делает с A зависит от действий, которые заложены в интерфейс X1.