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

А заодно -- испытать возможности обероновских "обработчиков".
Последние устроены так, что любой объект можно "научить" реагировать на любое сообщение, не ломая при этом существующую иерархию классов.
Гибкость получается большая, практически как в динамически типизированных языках ООП.
Но меня "гложут сомнения".
Вот я и задаю наивные вопросы, вроде: а не противоречит ли такая гибкость каким-нибудь принципам (например, принципу подстановки Барбары Лисков или еще каким-нибудь)?

Насколько я понимаю, такая возможность несколько противоречит принципу сокрытия информации:
Для того, чтобы обработчик мог сделать с объектом что-либо осмысленное, он должен иметь доступ к его внутреннему состоянию. То есть, либо все потенциальные обработчики должны быть реализованы в той же области видимости, что и "класс", либо мы  выставляем "внутренности" на всеобщее обозрение.
Более того, та же проблема (по крайней мере в Оберонах) возникает и с расширенными типами - обработчики, рассчитаные на базовые типы, не могут работать с "потомками", а обработчики "потомков" нуждаются в доступе к состоянию базовых типов.

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

Ответ на »сообщение 3998« (Руслан Богатырев)
___________________________

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

Зачем же смешивать рекурсию и порочный круг?

Речь шла о рекурсивном определении термина. Когда термин определяется через самого себя. Это не лучший способ давать определения, на мой взгляд.



И все же многие определения (хотя бы в какой-то степени) рекурсивны (рекуррентны).
Например, число Фибоначчи есть сумма двух предыдущих чисел Фибоначчи.
Нетерминальный символ "выражение" может определяться в том числе и через "выражение".
Решая упомянутую мной задачу о ступеньках, на одном из этапов совсем не грех определить решение для одного числа ступенек через решение для другого числа ступенек.
Согласен, что круга в определении быть не должно.
Но вот рекурсия, имхо, вполне может быть.

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


К сожалению, я не могу ответить однозначно на Ваш вопрос. Полиморфизм (дословно) - много форм, то есть, одно действие имеет несколько реализаций, одна сущность – много проявлений. Можно «сказать» птице – лети, и она полетит, можно «сказать» воздушному шарику – лети, и он полетит, хотя полет птицы и полет воздушного шарика основаны на разных принципах. Что в Вашем примере - Handle? Обработчик любых сообщений для любых объектов? Но причем здесь полиморфизм (тем более, наследование)? Представьте, что мне важно, чтобы используемые сущности умели летать (даже, если сущности не находятся в связях наследования). Это и есть «чистый» полиморфизм. Он позволяет абстрагироваться от используемых сущностей, другими словами, мы виртуализируем сущности посредством их общего свойства «летать». Такой подход действительно позволяет решить много проблем при проектировании и разработке системы.


Я просто пытаюсь понять, какими синтаксическими средствами можно поддержать "чистый полиморфизм". (Шаблоны не предлагать. :))
А заодно -- испытать возможности обероновских "обработчиков".
Последние устроены так, что любой объект можно "научить" реагировать на любое сообщение, не ломая при этом существующую иерархию классов.
Гибкость получается большая, практически как в динамически типизированных языках ООП.
Но меня "гложут сомнения".
Вот я и задаю наивные вопросы, вроде: а не противоречит ли такая гибкость каким-нибудь принципам (например, принципу подстановки Барбары Лисков или еще каким-нибудь)?


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

Вот это меня и заинтересовало!
Ведь должен такой полиморфизм иметь какую-то форму, пусть даже вне наследования.
Знание (хотя бы одной) такой конструкции и правда избавило бы меня (и, наверное, не только меня) от ряда проблем.

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

Зачем же смешивать рекурсию и порочный круг?

Речь шла о рекурсивном определении термина. Когда термин определяется через самого себя. Это не лучший способ давать определения, на мой взгляд.

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

Ответ на »сообщение 3968« (Как слышно? Прием!)
___________________________

Любите рекурсивные определения? Хорошо. Как Вы найдёте эти:
Расстояние -- величина, характеризующая расстояние от одного объекта до другого.
Множество целых чисел -- множество, каждый элемент которого является целым числом. Целое число -- элемент множества целых чисел. (неявная рекурсия)
Можно ещё кучу напридумывать, большей частью тривиальные.

Зачем же смешивать рекурсию и порочный круг?
Рекурсия уместна во многих случаях.
Например, синтаксис большинства языков программирования содержит рекурсивные конструкции.
Некоторые структуры данных рекурсивны (деревья).
Некоторые алгоритмы по природе рекурсивны (быстрая сортировка, переборные задачи).
Или подойду с другой стороны. Вы любите решать задачки?
Вот мне недавно на работе приятель задал задачку.
(Она легкая, я привожу ее в качестве иллюстрации, а не как "задание". :))

В лестнице N ступенек (для конкретности будем считать, что 10).
Мальчик может за один шаг подняться на 1 или 2 ступеньки, по выбору.
Сколькими способами он может преодолеть всю лестницу?

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

1. «Программирование-в-большом»... А потянете ли с таким грузом... стереотипов?
Что делать, приходится от чего-то отталкиваться. Уж извините, что оправдываюсь. Но ваш упрек звучит примерно как реплика “ООП... А потянете ли с таким грузом... стереотипов?”

2. Здесь глупо сравнивать языки а-ля Oberon vs. C++.
Сопоставляются Оберон (как представитель языков модульного программирования) и Java (как представитель языков ООП). Вы были невнимательны.

3. И верить нельзя, даже признанным кумирам... даже в тех вопросах, где их авторитет особенно высок. Можно, конечно, податься на поиски «серебрянных пуль» или «священного Грааля»... Ф. Брукс попытался, но вернулся с пустыми руками. И многие пытались... Н. Вирт, в их числе... А нам «не моги»... страшно должно быть...
Интересно выстроен поток мыслей. Абсолютно понятно все, что вы хотели этим сказать.

4. Особенно глупо выглядят попытки мыслить за других, а-ля:
Это не мысли за других, а собственные наблюдения, о чем и было сказано. Есть бо-о-о-льшая разница. Понимаю, что не нравится. Что делать...

5. Декарт, увы, не поможет.
Чем Декарт-то не угодил? Хуже, чем Сент-Экзюпери? Или претят цитаты? Кстати, обратил внимание, что в ваших работах практически нет ссылок на источники. Это такая позиция, стиль или просто я опять был невнимателен?

6. Но чем интересно данное обсуждение... Начали говорить о «наследовании», договорились до отмены, как самого «наследования», так и «инкапсуляции». Стали обсуждать «Поли-Морфизм»... до, чего только не договорились... Можно смело публиковать в разделе «Нелепости», без внимания данные здесь «определения» не останутся... Перешли к «классам» и «модулям»...
Повторю вашу фразу: “Особенно глупо мыслить за других”. Не сможете ли дать конкретные ссылки (пару номеров сообщений в форуме) на высказывания, где “договорились до отмены, как самого «наследования», так и «инкапсуляции»”. Видимо, был невнимателен, не заметил, когда и кто из оппонентов до такого успел договориться. К классам и модулям не перешли, с них, собственно, и начали.



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

1. Вы путаете понятия: «неприятие» и «апломб».
Вполне вероятно, что путаю. Однако, точно знаю, что апломб -- это чрезмерная самоуверенность. Вот иллюстрация моей мысли, привожу ваши же слова: “Например, я считаю что ни Г. Буч, ни Т. Бадд, ни многие другие «адепты» ничего не понимают в ООП.” Скажите, а есть кто-нибудь, кроме вас, кто понимает ООП и чьи работы можно почитать?

2. Мне трудно принять Ваши определения, по большей части они лишены смысла.
Интересно, и сколько же в течение дискуссии мне довелось давать определений? Приведите, пожалуйста, примеры таких определений и покажите, где они по большей части лишены смысла. Буду вам крайне признателен.

3. Хм... У нас с Вами разные точки отсчета (или наблюдения). В начале 90-х в вашем журнале «Мир ПК» вышла моя статья об объектном программировании на... ассемблере (правда, статью искромсали до безобразия, даже не поставив меня в известность...).
Если серьезно, то это печально. Упрек адресован мне (я такую статью точно не редактировал) или же изданию? Вы подписывали материал до выхода в печать? А если не подписывали и такое произошло, какие шаги предпринимали и предпринимали ли их вообще? Хотя я и выступаю в этом форуме как частное лицо, тем не менее, вроде как должен даже чувствовать себя виноватым.

4. Поэтому, Ваша точка отсчета (середина 90-х) -- мягко говоря, не совсем корректна. С ООП я дружу с середины 80-х...
Приведу выдержку из моего сообщения: “Вот ведь какая штука: развитие объектного подхода (как подхода к проектированию систем) началось, по моим наблюдениям, в середине 1990-х годов. До начала 1980-х годов о самом ООП, из которого подход и вышел, вообще даже не говорили.” Скажите, пожалуйста, каким образом приведенные вами факты работы одного отдельно взятого коллектива (кстати, можно ли познакомиться с вашими работами по данной тематике, датированными серединой 80-х годов?) противоречат смыслу моей фразы?

5. Судя по Вашему отзыву Вы не удосужились познакомиться с «представленными материалами». О модульном программировании в материалах говорится... в самом начале. Я понимаю, что Вы «писатель», но... давая рецензию, хотя бы ознакомьтесь с тем, о чем говорите.
Я посмотрел еще раз ваши материалы и согласен, что был невнимателен. В них действительно содержится информация о модульном программировании и его особенностях. Тут я был не прав. Признаю и приношу извинения. Но зачем же так сразу вешать ярлыки? Какие штапмы: “не удосужились”, “писатель”! Нехорошо это.

6. Мне трудно принять Ваш стиль разговора (банальное начетничество), за которым не чувствуется ни личного опыта, ни глубоких размышлений.
Понимаю вашу обиду на мою невнимательность и на искромсанную статью в журнале.
Но здесь вы явно погорячились. Навешивать ярлыки -- не лучший способ ведения дискуссии. Давайте зададимся вопросом, что означает слово начетничество:

Мне известно два значения:
1. Знания, основанные на механическом, некритическом усвоении прочитанного.
2. Способ усвоения, связанный с догматическим отношением к прочитанному.

Дискуссия началась с того, что я завел разговор о модульном программировании и его месте в современном мире. Отметил, что практически нет основополагающих классических работ по этой теме, что даже с ключевым понятием “модуль” существует путаница. Отметил, что ООП сегодня, на мой взгляд, характеризуется гегемонией, диктатурой. Это критический взгляд, не догматический. О какой догме вы ведете речь? Действительно, интересно в этом разобраться. Вы можете привести примеры работ, в которых излагаются те мысли, что я представил?

7. К слову об определениях. Определение -- один из способов передачи смысла, но проблема в том, что передать смысл... нельзя. Воспринять, обрести - можно, но передать нельзя.
С философской точки зрения ваше высказывание понять можно. Но с практической -- зачем нужен один из способов передачи смысла, если его, этот смысл передать нельзя? Зачем нужны терминологические словари со словарными статьями? Они дают “голую информацию” ни о чем или все же наполняют определенным смыслом слова в данной предметной области? Зачем вообще вводят термины? Может быть проще и легче говорить простыми и понятными словами? Или все же сложнее? Может ли термин быть без своего определения? Думаю, вряд ли.

8. Рассуждения -- приятное времяпрепровождение, не более того. Чтобы они имели хоть какую-то ценность, необходимо, дабы в них был смысл. Но смысл сначала надо открыть.
Риторический вопрос: зачем же смысл открывать, если передать его, как выясняется, нельзя? Ваш укол мне понятен. Но без конкретики он не более чем очередной ярлык.

9. Простите, но именно его я и не вижу в Ваших высказываниях.
Жаль, видно вы, как и я, были не очень внимательны и поспешны в своих выводах.

Ответ на »сообщение 3989« (AVC)
___________________________
Я нашел у Вас интересное утверждение, что разделение полиморфизма и виртуальности (наследования) позволяет решить многие проблемы.
Вот мой вопрос.
Позволяет ли обероновский подход с "обработчиками" добиться того же самого?
К сожалению, я не могу ответить однозначно на Ваш вопрос. Полиморфизм (дословно) - много форм, то есть, одно действие имеет несколько реализаций, одна сущность – много проявлений. Можно «сказать» птице – лети, и она полетит, можно «сказать» воздушному шарику – лети, и он полетит, хотя полет птицы и полет воздушного шарика основаны на разных принципах. Что в Вашем примере - Handle? Обработчик любых сообщений для любых объектов? Но причем здесь полиморфизм (тем более, наследование)? Представьте, что мне важно, чтобы используемые сущности умели летать (даже, если сущности не находятся в связях наследования). Это и есть «чистый» полиморфизм. Он позволяет абстрагироваться от используемых сущностей, другими словами, мы виртуализируем сущности посредством их общего свойства «летать». Такой подход действительно позволяет решить много проблем при проектировании и разработке системы.

Здесь в числе аргументов обработчика содержатся как сам объект, так и сообщение. Значит, здесь задействованы одновременно две иерархии -- объектов и сообщений.
В общем случае, сообщения могут не создавать иерархии. Но и соединение двух иерархий еще ничего не говорит о виртуализации. Это несколько разные понятия. Возможно я не понял Вашего вопроса/примера.

Приведенные Вами примеры со свойствами "иметь цветы" и "иметь плоды" в Си++, наверное, могли быть реализованы как примеси, а в Обероне (имхо) с помощью обработчиков
Увы, это не мой пример, а пример Г. Буча. Я привожу этот пример, как... пример неправильного проектирования (простите за тавтологию).

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

Ответ на »сообщение 3967« (Сергей Губанов)
___________________________
Круто! Жалко только что Вы эту ссылку раньше не дали. Теперь можно подумать как ответить на Ваш вопрос: "Как на Обероне писать сложные системы?".
Если мне не изменяет память, то ссылку я приводил несколько лет назад на progz.ru. А на вопрос отвечать не спешите... вдруг ответ Вас разочарует.

Ответ на »сообщение 3964« (Руслан Богатырев)
___________________________
Ну вот, Александр Сергеевич, теперь мне более-менее понятна природа того "апломба", с которым были сделаны ваши экспресс-комментарии.
Вы путаете понятия: «неприятие» и «апломб». Мне трудно принять Ваши определения, по большей части они лишены смысла. Мне трудно принять Ваш стиль разговора (банальное начетничество), за которым не чувствуется ни личного опыта, ни глубоких размышлений. Вы жонглируете датами и цитатами, не всегда понимая предмет разговора, IMHO (разумеется).
К слову об определениях. Определение – один из способов передачи смысла, но проблема в том, что передать смысл... нельзя. Воспринять, обрести - можно, но передать нельзя. И если присмотреться, то можно легко заметить, что в современной науке существует масса определений не имеющих никакого смысла. Эти определения появляются и исчезают... Парадокс в том, что «неопределенными» являются базовые понятия любой науки: материя, личность, интеллект, жизнь и т.п. А Вы упорно «цепляетесь» за определения... Впрочем, все это уже многократно обсуждалось в соседней дискуссии...

Судя по представленным материалам, вы убежденный сторонник объектного подхода. Достаточно интересно были читать о том, что переход к объектной технологии произошел от структурного программирования и подпрограмм.
Судя по Вашему отзыву Вы не удосужились познакомиться с «представленными материалами». О модульном программировании в материалах говорится... в самом начале. Я понимаю, что Вы «писатель», но... давая рецензию, хотя бы ознакомьтесь с тем, о чем говорите.

Вот ведь какая штука: развитие объектного подхода (как подхода к проектированию систем) началось, по моим наблюдениям, в середине 1990-х годов. До начала 1980-х годов о самом ООП, из которого подход и вышел, вообще даже не говорили
Хм... У нас с Вами разные точки отсчета (или наблюдения). В начале 90-х в вашем журнале «Мир ПК» вышла моя статья об объектном программировании на... ассемблере (правда, статью искромсали до безобразия, даже не поставив меня в известность...). А до ассемблера я уже много чего попробовал не только среди языков, но и в реальных проектах. Те материалы, которые Вы «рецензировали», тоже сформировались в начале 90-х, а написаны были в где-то в середине 90-х годов, после долгих (многолетних) дебатов в FIDO... И проект системы «КУБ», интересен тем, что в нем использованы иные (нетрадиционные) подходы к формированию команды, к архитектуре системы, к ее внедрению и развитию. Ну, представьте, что разработчики были набраны по объявлению буквально перед началом работы, 70% из них вчерашние выпускники, которые не имели практического опыта работы. Тем не менее, системы была создана за 1,5 года (порядка 20 чел. лет). В то время, как аналогичные проекты разрабатываются по 2500 – 5000 чел. лет и далеко не новичками. Другими словами, наша разработка была сделана на два порядка(!) быстрее. Да, и в самой системе заложено много такого, чего нет у самых именитых аналогов. Говорю я это не для того, чтобы похвалить себя, а для того, чтобы Вы немного задумались об ООП, о котором отзываетесь весьма небрежно, к сожалению, не понимая сути.
Надеюсь Вы понимаете, что подходы и методы, использованные нами не «вчера родились». Поэтому, Ваша точка отсчета (середина 90-х) – мягко говоря, не совсем корректна. С ООП я дружу с середины 80-х...

Вот почему я предпочитаю просто рассуждать. Рассуждать вслух. Даже если это ровным счетом никому и не надо.
Рассуждения – приятное времяпрепровождение, не более того. Чтобы они имели хоть какую-то ценность, необходимо, дабы в них был смысл. Но смысл сначала надо открыть. Простите, но именно его я и не вижу в Ваших высказываниях.
Что касается ООП, то о нем есть много разных представлений. Например, я считаю что ни Г. Буч, ни Т. Бадд, ни многие другие «адепты» ничего не понимают в ООП. Можно привести много примеров откровенных нелепостей, которые они допускают пускаясь в рассуждения об ООП. В свое время я даже начал писать статью под названием «Взбучка (vs. Booch-car)», но фактического материала (читай, - нелепостей) был слишком много и мне это быстро надоело. Однако я избегаю... обобщать понятие ООП, слишком различно воспринимаются/подаются даже основополагающие понятия (не по форме, но по сути).

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

Предлагаю такую зацепку для определения модуля. Модуль и тип данных не тождественны (в отличие от классов и типов данных). Да по-моему, эта мысль уже высказывалась кем-то из участников дискуссии.

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

Класс подразумевает существование своих экземпляров, модуль -- ровно одного, уникального.

А как быть с полиморфизмом и наследованием? Что-нибудь из этого модуль поддерживает или нет?