Ответ на »сообщение 4074« (hugi)
___________________________
Ответ на »сообщение 4073« (ASU)
И автор этой брошюры второй после Вас, кто понимает, что такое ООП. :)
Нет, это я после него... :)

Видимо Буча, так Вас рассмешившего, всё-таки невнимательно читали. Он  в своём "ОО Проектировании" наглядно показывает, что "хороших" классификаций не бывает
Фи... "Виноград зелен" - сказала лиса, не сумев дотянуться до гроздьев. (Эзоп).

Ответ на »сообщение 4072« (hugi)
___________________________
затрагиваете, насколько я понял, другую проблему -- динамическое изменение функциональности. А это, на мой взгляд, вряд ли имеет что-то общее с полиморфизмом в понимании ASU, ибо в его примере функциональность уже заявлена, и одинакова для разнородных объектов (Птица и ВоздушныйШар), т.е. ничего менять не нужно (т.е. можно, но только реализации функции Летать, а иными словами (на более низком уровне) -- нужно менять обработчики сообщения Летать, а набор сообщений менять не нужно)
Эх... Тема-то какая!.. Динамическое изменение функциональности. ЗдОрово, хотя не [всегда] здорОво.
Наверное, надо различать три положения:
а) псевдо-изменения функциональности;
б) статическое (псевдо-динамическое) изменение функциональности;
в) динамическое изменение функциональности.

А. Псевдо-изменения функциональности
Суть: класс обладает полиморфными свойствами (интерфейсами, если желаете). Свойства (статически или динамически) группируются в роли. Если посмотреть на объектную иерархию у Т. Бадда, то у него как раз роли, в которых может выступать объект, перепутаны с наследованием. Почтальон или садовник - это не субклассы (потомки) класса Homo Sapiens, но его роли. Один и тот же объект может выступать в разных ролях (в том числе, одновременно!). Можно сказать иначе: роль специфицирует тот набор свойств, которыми должен обладать объект (класс). В этом случае виртуализация на основе полиморфного свойства - частный случай виртуализации на основе роли. Объект не может обретать новую функциональность, но(!!!) он может "освоить" новую роль. Внешне это выглядит именно так, что объект динамически приобрел новое свойство (не забываем, что извне должны быть видны только интерфейсы или их группы - роли), но внутри... конечно, ничего нового у объекта не появилось (и ни какого изменения в кодах не происходит, соответственно, и никакой перекомпиляции...). Далее раскрывать не буду, времени нет, да, и понятно, наверное.

Б. Статическое (псевдо-динамическое) изменение функциональности
Данное изменение, тоже в реальности не является изменением функциональности. Говоря "философским" языком, это накопление количественных (но не качественных) изменений. Статические изменение характерны для агрегатов (контейнеров). Мы можем заменить в агрегате один объект на другой (даже на объект другого класса, способный выступать в той же роли). Как правило, такую замену не рекомендуется делать "на ходу". Ну, не пытаемся же мы заменить карбюраторный двигатель на дизельный, не останавливая автомобиль... Надо "вывести" агрегат в нерабочую зону и там произвести замену. На практике это означает, что мы должны закрыть поступление новых сообщений (заданий) к агрегату, дождаться завершения последнего действия, "завести агрегат в бокс" и там сделать замену. Что представляет собой "бокс"? Эта такая область, как правило, в объектной среде (фабрике), где становится доступно устройство агрегата (аналог ремонтной мастерской). Примитивный вариант "бокса" - перегрузка ОС после очередного "обновления". Замена частей агрегата может создать и дополнительную функциональность, либо как в п. А, либо... (хотя это либо крайне не рекомендуется!!!).

В. Динамическое изменение функциональности
Это замена колес автомобиля... во время движения. Любители экстрима могут занимать очередь :)

Ответ на »сообщение 4067« (Сергей Губанов)
___________________________
Ответ на »сообщение 4066« (Владимир Лось)
...CALL/RET...
Проблема не только техническая.
Правильно, но именно от того, как организован самый нижний уровень реализации "интимного общения" активных сущностей в операционной системе, зависят все остальные проектные решения при построении ПО в этой системе.
Например, в системах с чётким CALL-RETом я и проверить-то не могу есть ли у меня в данный момент нужный код или данные (без кучи дополнительных наворотов типа учёта ссылок и проч.). Но, если у меня есть микроядро с механизмом обмена сообщениями я имею идеальное разделение модулей в адресном пространстве и абсолютно(!) безболезненно и безопасно получаю -1 из функций MsgSend или MsgReply... Конкретное приложение может выпасть в корку, но всё остальное ничего не замечает.
Я как-то предложил в письме Зуеву реализовать Зоннон над QNX или ещё каким микроядерным исзделием. Там ведь каналы один-в-один отображаются на систему обмена сообщениями. Но, оказалось, что в Цюрихе про QNX даже не слышали... :о)

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

Рассыплешь колоду...
Э-эх, золотые денечки... Девочки за перфораторами...

а банальной необходимостью.
Вот.
Банальная необходимость -- твердая опора среди... идей.

идеи ООП не носили эволюционного характера.
Суждение... субъективное, конечно. Молодой человек читает таинственный манускрипт с... идеями. Ясно... революция.

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

иерархии начали строить на потребу...
Хорошо если хоть на какую-то потребу. А то часто ведь просто так -- по... "сложившейся традиции".

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

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

Типы данных, как я уже говорил, в этих языках есть. Единственное отличие от строго типизированных языков состоит в том, что в динамически-типизируемых языках переменная может менять тип по ходу выполнения, но всё же в любой момент времени можно сказать, к какому типу относится переменная. Пример тому уже упомянутый мной PHP. Предвидя Ваши возражения поясню вышесказанное на примере. Предположим, у Вас есть две переменных X = 'abcd' Y = 3.345 и Вы хотите их сложить.

Надо бы все же отличать типы переменных от типов данных (значений).
Смысл для классификации языков имеют все-таки типы переменных.
А операции производятся над значениями (хотя проекции a ----> a[i] или a.b это тоже операции, хотя и не в терминологии Сообщений об Оберонах; но это все равно не те операции, о которых говорится в цитате).

Теперь рассмотрим, почему мы могли бы запретить выполнение этой операции. Других причин не вижу, кроме явной разнородности значений переменных. А что есть разнородность, как не принадлежность к разным ТИПАМ объектов.

Глубоко :-)
Это ASU всех тут научил "Хм." говорить.
Правда, не у всех правильно получаетца.
(Подсказка: после "Хм" надо ставить многоточие.)

Забавное, все-таки, чтение в бессонницу этот форум.

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

и была потребность перегружать части программ, а для этого надо было сначала разделить программу на эти самые части – перегружаемые модули (overlay module).
Эти два направления неизбежно должны были соединиться, что и послужило причиной рождения модульного программирования. То есть, проблемы были осмыслены и предложено решение в виде расширений возможностей традиционных языков и появления новых языков программирования. Другими словами, модульное программирование являло собой эволюционный шаг, в продолжение идей структурного программирования

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

В отличие от модульной, появление объектно-ориентированной парадигмы не носило эволюционный характер. Собственно, никаких особых предпосылок для изменения стиля мышления не было, была просто красивая идея... В те времена в нашей стране не было не только Интернет, но и... доступной литературы.

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


Собственно, в брошюре были изложены только самые общие принципы и понятия, а для наглядности приведена пара фрагментов на SmallTalk.

он тода так и назывался в той брошуре? часом не смолток? а по англицки не Smalltalk? хто же T поднял верх?

«Сращивание» модулей и объектов начало происходить позже, когда появились практические исследования в области ООП.

и кода по вашему енто было и где?

Класс – это лишь описание, выделение/определение значимых признаков (не только в программировании, но в любой классификации).

ну загнул! а .class в жабе енто чо?

И в этом смысле, класс может быть аналогичен текстовому описанию модуля (оперирующему одной сущностью!). Объект, как экземпляр класса, это типичная реализация, как и откомпилированный модуль (создаваемый/подгружаемый отдельно или в составе программы). И здесь нет противоречия.

ага ага. класс енто текст, а объект енто реализация. значит класс енто до компиляции, а объект опосля линковки.

В основе ООП не лежит решение частных задач, важнее получить семантически стройную иерархию классов.

модули значит нужны для часных задач, а ооп для стройной ерархии. вона зачем!

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

Так мне в руки попала небольшая брошюра (страниц на 10-15) по объектно-ориентированному программированию.

И автор этой брошюры второй после Вас, кто понимает, что такое ООП. :)

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

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

Модуль... класс... слова... слова...
Понятие модуля формировалось двумя путями. С одной стороны, тексты программ становились все больше и больше, а большими текстами работать было очень неудобно. Наверное, надо вспомнить, что средств отладки (в современном понимании) не было. Да, и основным средством переноса программ были... перфокарты. Рассыплешь колоду... Поэтому деление программ на отдельные части, раздельная компиляция и пр. были не прихотью, ни средством получения «эстетического удовольствия», а банальной необходимостью.
С другой стороны, возможности компьютеров были весьма ограничены. Это сейчас по 0,5 Гб на... видеокарте, а тогда оперативной памяти было 1 Мб, а на таком компьютере «висело» по 30-40 терминалов. И, конечно, не хватало оперативной памяти, и была потребность перегружать части программ, а для этого надо было сначала разделить программу на эти самые части – перегружаемые модули (overlay module).
Эти два направления неизбежно должны были соединиться, что и послужило причиной рождения модульного программирования. То есть, проблемы были осмыслены и предложено решение в виде расширений возможностей традиционных языков и появления новых языков программирования. Другими словами, модульное программирование являло собой эволюционный шаг, в продолжение идей структурного программирования. Собственно, модуль тоже является структурной единицей программы. Но было бы неверно считать, что модуль – это развитие понятие структуры (structure, record). Структура – это логическая часть программы (логика программы – данные (структурированные, в том числе) и код), модуль – организационная часть программы (загрузочные модули, исполняемые модули, перегружаемые модули и пр.). Были даже языки (например, JCL – job control language) управляющие выполнением задания (программы), которые контролировали загрузку, исполнение, перегрузку и т.п.
В отличие от модульной, появление объектно-ориентированной парадигмы не носило эволюционный характер. Собственно, никаких особых предпосылок для изменения стиля мышления не было, была просто красивая идея... В те времена в нашей стране не было не только Интернет, но и... доступной литературы. Издавали очень мало, то что издавалось расходилось по «карточкам» (была такая система: издательства публиковали планы выпуска книг на следующий год, и в момент издания этих планов в некоторых магазинах можно было подписаться на книги, указанные в планах. О появлении планов (обычно в ноябре) издательств знали заранее и к книжным магазинам задолго до открытия выстраивались очереди. Иногда везло...) Тем не менее, литература издавалась... типичным для того времени способом – самиздатом. И вычислительные центры по всей стране играли в этом не последнюю роль. С каждой конференции привозили огромное количество книг, статей, сборников на «ленточках» и «томах». А потом долгими ожиданиями очереди на исполнения своего задания все это просматривалось, отбиралось и печаталось. Чего только не было в этих оцифрованных «книжных развалах»: Гумилев, Высоцкий, Войнич... и конечно, книги по программированию. Так мне в руки попала небольшая брошюра (страниц на 10-15) по объектно-ориентированному программированию. Собственно, в брошюре были изложены только самые общие принципы и понятия, а для наглядности приведена пара фрагментов на SmallTalk. Так, вот, ссылаясь на этот источник, сомнительного происхождения, смею утверждать, что идеи ООП не носили эволюционного характера. Идея создания классификации на основе понимания семантики сущностей и оперирование сущностями, исходя из их предназначения... это было совершенно необычно для программистов, привыкших иметь дело с задачами и программами.
«Сращивание» модулей и объектов начало происходить позже, когда появились практические исследования в области ООП. И такое «сращивание» выглядело вполне логичным, поскольку модуль, оперирующий только одной сущностью можно считать прообразом объекта (это замечание относится к реализации, но не к концептуальному решению). В отличие от объектов, модули к тому времени имели практические реализации, и  это не могло не сказаться на воплощении концепций ООП. Аналогии выстраивались достаточно легко. Класс – это лишь описание, выделение/определение значимых признаков (не только в программировании, но в любой классификации). И в этом смысле, класс может быть аналогичен текстовому описанию модуля (оперирующему одной сущностью!). Объект, как экземпляр класса, это типичная реализация, как и откомпилированный модуль (создаваемый/подгружаемый отдельно или в составе программы). И здесь нет противоречия. Но все же ООП и модульное программирование, конечно, не тождественны. Дело даже не в том, что в модульном программировании нет ни наследования, ни полиморфизма... Дело в подходе к разработке. В основе ООП не лежит решение частных задач, важнее получить семантически стройную иерархию классов. Об этом забыли... иерархии начали строить на потребу... Потому сегодня проводить межи и расставлять разделительные вешки между модульным программированием и ООП... пустая трата времени, IMHO. Но разговор о семантическом моделировании и принципах построения хороших классификаций... совсем другая тема.

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

Может, я заблуждаюсь, но, на мой взгляд, Вы смешиваете две разные проблемы.
Сначала Вы говорили о разделении полиморфизма и наследования, опираясь на неформальное определение полиморфизма, данное ASU:

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

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

Когда же Вы говорите:

Но интерфейсы сами по себе не позволят мне менять набор обрабатываемых объектом сообщений "на лету", без перекомпиляции.

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