Ответ на »сообщение 4133« (sdf)
___________________________
ну знатоки! возьмите enumeration где ваще нет ничего окромя равно неравно. какая там функциональность? или не тип?
Не горячитесь. Сначала решите для себя (ответьте) на очень простые вопросы:
Для чего обычно в ЯП служит тип перечисления?
Как вы отличаете "этот" тип перечисления от "того"? Не только текстуально, но во время выполнения программы?
Какие операции "общепринято" производить над переменными того или иного "типа" перечисления?
(наводящий вопрос :о) ) Можете ли вы вывести обобщённый класс, представляющий в программах "тип перечисления"? Определите набор интерфейсов, которые необходимы для работы с переменными этого класса. Попробуйте решить эту задачу на двух языках: Си++ и Смолток.

Если "глубокоооооо задуматься" :о) , выяснится, что просто так "из воздуха" полимрфизм не появляется. При всей возможности высокоуровневой абстракции, за ней стоят конкретные объекты, заявляющие, что они под этим имененм предлагают (определяют, реализуют) конкретную операцию (семантика оговаривается отдельно).
Полиморфизм появляется на границе объектов, на интерфейсе (не в смысле ЯП, а в более общем понятии - месте взаимодействия объектов).
о! да мы не в курсе полиморфных операций! полиморфизм енто тока в ооп? три ха ха! енто хто вам такую чушь сказал? уж не asu ли?
Наличие у объекта возможности предоставить какую-то операцию – конкретное свойство объекта. Совпадение имён (обозначений) операций – либо требование задачи (после стадии анализа), либо ... случайность... :о)
Я не пойму, почему такое высокомерие. "Мы" – в курсе. ("Они понимают."(с) Калиостро из "ФЛ") Иначе бы очень трудно было заниматься классификацией и строить программы, используя ОО-языки... :о)

да замусолили. сплошной базар. енто все мысля про оберон.
Если вы заглянете в САМЫЕ первые сообщения, то увидете, что мной как раз и было высказано пожелание не только об обероне здесь говорить.
Или вам нужно, что бы "всё было попендикулярно, параллельно и окрашено в зелёный цвет"? Вы что думаете, здесь народ на почве ООП схлёстывается единственно по причине недостатка знаний в этой области? "три ха-ха"(с) sdf........

Ответ на »сообщение 4119« (hugi)
___________________________
>>>Но мы что-то уже ушли от предмета нашей дискуссии.
Ах, да. Если кратко: в «статически типизированных» языках тип - синтаксическая категория, а в
«динамически типизированных» языках тип – внеязыковое понятие

Ответ на »сообщение 4129« (Владимир Лось)
___________________________

...как это дело объявляется в Лимбо:

Владимир, у меня к Вам одна ма-а-а-аленькая просьба: если можно, в следующий раз потрудитесь, пожалуйста, если уж приводите пример, пояснять его. Просто времени сейчас в обрез, и тратить его на ковыряние в Limbo, нет ну решительно никакой возможности. Мне кажется, я понял Вашу мысль, но уверенности в этом нет.

Сами видите: подавайте на вход функции sort(), во-первых, аргумент s, ЛЮБОГО ТИПА S (лишь бы в его составе была функция нужной сигнатуры и семантики) и массив a элементов любого типа, лишь бы он согласовался с типом аргументов функции сравнения – и получаете рабочую функцию без необходимости городить набор дополнительных синтаксических конструкций.

В приведённых мной способах тоже никаких особых синтаксических конструкций не требовалось.

То же самое и в отношении свойства "летать". По задаче у меня могут появиться соврешенно извратные желания на счёт того, что должно уметь летать. Множественным наследованием можно такого же добиться, но довольно велик шанс возникновения противоречий и не стыковок (соврешенно разного характера: от правил оформления наследования, через конфликты имён и к просто логической нестыковке "интерфейсов" при реализации)...


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

Выходит, вы её неправильно понимаете... Или не в курсе последних "веяний"... Ну, или, "на крайняк", её не правильно понимают Керниган с Томпсоном и Ричи (аки авторы Инферно и Лимбо... :о)

Они её по-своему реализовали, но смысл не поменялся. И, раз уж на то пошло, у них уже не АТД, а, скорее, классы, где данные объединены с операциями, и обращение к объекту происходит через посылку сообщения. В АТД такого нет.

Да, но, если следовать вашей логике, то абсолютное "абстрагирование от классов" сводит класс просто к роли держателя (объединителя, контейнера) реализаций интерфейсов. А при этом мы вполне логично приходим к единственному "типу" класса в системе – "типу"-держателю интерфейсов... :о) Чем тогда один от другого эти классы по реализаци механизмов поддержки этого свойства будут отличаться? :о)

А что такое класс, как не "держатель интерфейсов", он ведь и так предоставляет определённый интерфейс, просто концепция Интерфейсов (буду писать с большой буквы, чтобы избежать путаницы) позволяет сделать иерархию классов более гибкой, накладывая  на неё иерархию интерфейсов. А отличаться классы будут тем же, чем всегда отличались. Класс Птица отличен от класса ВоздушныйШар, хотя и тот и другой умеют летать (реализуют интерфейс УмеющийЛетать).

Другая сторона этой же крайности: представьте, что все интерфейсы свелись (каждый в своём наборе функций) К ЕДИНСТВЕННОЙ ФУНКЦИИ. Просто, интерфейс состоит всего-лишь из одной функции. Каждый. Чем они для системы поддержки времени будут друг от друга отличаться? Ведь вы же сказали, что имена не имеют значения! :о)

Вы о чём, вообще? Какая система поддержки времени? Ничего не понимаю...

Господа, задавайте себе вопросы, крутите, "мусольте" тему. Смотрите на неё так и эдак... Никто не сказал, что знания задаются на века. Всё текёть, всё зминюеться...


К Вам это тоже относится...

Чем больше читаю этот форум, тем больше не понимаю, о чем собственно речь-то идет :)). Что такое наследственность, что такое полиморфизм, что такое модуль... Жил себе жил, писал программки в с/с++, дельфях, паскале, блэкбоксе, пользовался имеющимися средствами..., а теперь все больше желания не читать подобные заумные вещи. А единого мнения и нет, кто на что ссылается, кто на Буча, кто на Мейера, кто на Вирта... Как в книге одной: В нашей стране существует 36 методик преподавания.... :(

Ответ на »сообщение 4129« (Владимир Лось)
___________________________

Господа, задавайте себе вопросы, крутите, "мусольте" тему. Смотрите на неё так и эдак... Никто не сказал, что знания задаются на века. Всё текёть, всё зминюеться...

да замусолили. сплошной базар. енто все мысля про оберон.

Ответ на »сообщение 4130« (ASU)
___________________________

Но попробуйте смотреть на роль, как на совокупность интерфейсов. Интерфейсы уже есть, их осваивать заново не надо, надо их только упорядочить...

ну ну. пасматрю я как вы приладите роль садовник для homo erectus. слыхали о таком? али не человек ужо?

Ответ на »сообщение 4131« (ASU)
___________________________

«Наследование» в ООП основано на выявлении родовых (общих свойств), которые передаются от суперкласса его подклассам.

держите меня! наследование тока от суперкласса? енто значит все другие наследуют тока от оного а не от других родичей по отцовской линии? ха ха

Ответ на »сообщение 4101« (Владимир Лось)
___________________________

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

о! да мы не в курсе полиморфных операций! полиморфизм енто тока в ооп? три ха ха! енто хто вам такую чушь сказал? уж не asu ли?

Ответ на »сообщение 4129« (Владимир Лось)
___________________________

Насколько я понимаю концепцию АТД, тип данных определяет именно данные, а не функциональность. Функциональность определяется производимыми над переменными этого типа операциями.
Выходит, вы её неправильно понимаете... Или не в курсе последних "веяний"... Ну, или, "на крайняк", её не правильно понимают Керниган с Томпсоном и Ричи (аки авторы Инферно и Лимбо... :о)

ну знатоки! возьмите enumeration где ваще нет ничего окромя равно неравно. какая там функциональность? или не тип?

Ответ на »сообщение 4125« (AVC)
___________________________

А в Обероне нельзя достичь этого эффекта при помощи композиции объектов? ...
Интересно, насколько применим такой подход за пределами визуализаторов?

Можно. Применим широко.

Тут bandwidth узкий. Если будет желание встретиться, перетерли бы все это конкретно.