Ответ на »сообщение 4089« (info21)
___________________________
Замена колес, конечно, не совсем удачный пример в плане изменения функциональности. Но можно уточнить.
Автомобиль = ядро QNX + то, что загружено вместе со своим state.
Перегружать оное = "обдефолтить" этот самый state, т.е. остановить автомобиль.
Я понимаю ваши затруднения. Для добавления новой функциональности (при имеющихся аппаратных ресурсах) мне ДЕЙСТВИТЕЛЬНО НЕ НАДО останавливать QNX. Другое дело - как написана конкретная программа. Это уже дело отдельного программиста, использовать ли возможности ОСи для "чудес"...
Пример с автомобилем удачный. Неудачно выбраны сущности для примера. Говорить было бы лучше об автомобиле и ... замене дорожного полотна... :о)))

Ответ на »сообщение 4068« (hugi)
Не напомните, что Вы демонстрировали (точнее какую мысль иллюстрировали)?

То что модульные системы возможно писать на не модульных языках.

Насколько я понял слова Руслана Богатырёва, они значат, что язык может быть модульным и тогда, когда на нём не пишутся модульные системы, но который имеет в своём составе конструкцию модуля

Если нет модульной системы, то нет и модулей. Потому что модуль - он не просто так, а модуль системы.

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

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

И всё-таки ответьте, пожалуйста на вопрос:"Может ли язык быть модульным и не модульным одновременно?"

Может ли быть удобно и не удобно одновременно? Можно ли одновременно иметь специальное предназначение и не иметь его? Можно ли одновременно быть оптимизированным и не быть им?

Ответ на »сообщение 4069« (hugi)
Типы данных, как я уже говорил, в этих языках есть...

Вот программа на языке Mathematica:

f[x_] := x;

Я утверждаю, что x - это переменная, а f[] - функция. И вряд-ли кто-либо с этим не согласится. Что позволяет мне утверждать, что x - это переменная? Что-то позволяет, но типы тут не причём. То есть понятие переменной, вообще говоря, не связано с понятием тип.

Ответ на »сообщение 4073« (ASU)
«Сращивание» модулей и объектов

Грубо говоря:
Модуль - это DLL.
Объект - это структура в памяти.

DLL будучи загруженной в память, конечно представляет некую структуру в памяти, в этом смысле модуль выступает в роли объекта. На этом сходство между модулями и объектами заканчивается.

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

В. Динамическое изменение функциональности
Это замена колес автомобиля... во время движения.
Не вижу препятствий...
В QNX я могу, не останавливая систему, перегружать ВСЁ, кроме микроядра, обеспечивающего такую гибкость.

Замена колес, конечно, не совсем удачный пример в плане изменения функциональности. Но можно уточнить.
Автомобиль = ядро QNX + то, что загружено вместе со своим state.
Перегружать оное = "обдефолтить" этот самый state, т.е. остановить автомобиль.

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

Ответ на »сообщение 4086« (sdf)
___________________________
у класса есть интерфейс и свойства значит они полиморфные. у модуля тоже интерфейс и тоже свойства и тоже полиморфные, так получается? а какие тода свойства неполиморфные?
Свойства не полиморфны "сами по себе". Они вообще не обладают такими качествами. Полиморфность выражается на уровне сущностей-носителей свойств. Удовлетворение конкретного свойства набору определенных требований делает его носителя полиморфным.

Ответ на %???? (ASU)
В. Динамическое изменение функциональности
Это замена колес автомобиля... во время движения. Любители экстрима могут занимать очередь :)
Не вижу препятствий...
В QNX я могу, не останавливая систему, перегружать ВСЁ, кроме микроядра, обеспечивающего такую гибкость.

Б. Статическое (псевдо-динамическое) изменение функциональности
Данное изменение, тоже в реальности не является изменением функциональности
Само существование QNX опровергает ваши слова... :о)

Ответ на »сообщение 4073« (ASU)
___________________________
Понятие модуля формировалось двумя путями. С одной стороны, тексты программ становились все больше и больше, а большими текстами работать было очень неудобно. Наверное, надо вспомнить, что средств отладки (в современном понимании) не было. Да, и основным средством переноса программ были... перфокарты. Рассыплешь колоду... Поэтому деление программ на отдельные части, раздельная компиляция и пр. были не прихотью, ни средством получения «эстетического удовольствия», а банальной необходимостью.
Что-то заставляет меня не совсем быть согласным...
Никогда не думал о программе, как о ТЕКСТЕ. Действительно ТЕКСТ для меня был последней вещью, о которой я "задумывался в сторону" программы.
Текст естественно, является средством выражения семантики, что мы хотим получить от программы, но "модульность – из  требований разделения ТЕКСТА" – это весчь "почище Фауста Гётте" :о) Это, скорее всего, сформировалось под ОЧЕНЬ сильным вляинем Си-культуры...

... И, конечно, не хватало оперативной памяти, и была потребность перегружать части программ, а для этого надо было сначала разделить программу на эти самые части – перегружаемые модули (overlay module).
А не помните, случаем, как это в четвёртом фортране на эСэМ-ках делалось в RSX или RT-11? Это так, чиста намёк... :о)

Эти два направления неизбежно должны были соединиться, что и послужило причиной рождения модульного программирования.
Я прозрел!
То есть до этого многолетние наработки по абстракции типов данных и поиск оптимального выражения (формализма) этого языковыми средствами, на Марсе проводились? :о)

Но было бы неверно считать, что модуль – это развитие понятие структуры (structure, record). Структура – это логическая часть программы (логика программы – данные (структурированные, в том числе) и код), модуль – организационная часть программы (загрузочные модули, исполняемые модули, перегружаемые модули и пр.).
На счёт средств представления АТД исчё раз позволю себе напомнить.
А вот то перечисление типов модулей – скорее всего от традиции владения языками, не поддерживающими модульность. Там естественным является такой подход. Иначе просто и быть не может: задания, пакеты, оверлеи, чанки, кластера...

Были даже языки (например, JCL – job control language) управляющие выполнением задания (программы), которые контролировали загрузку, исполнение, перегрузку и т.п.
Вот-вот-вот! :о)  (см. выше)...

В отличие от модульной, появление объектно-ориентированной парадигмы не носило эволюционный характер.
А что – революционный?
Не согласен. Там, как раз, революции не было.
Просто модульные языки дают строить расширяемые системы, а ООП – программы.
Просто не всем расширяемые на уровне ОСи системы нужны. 99% процентов "живут" и "варятся" на уровне своего маленького мирка своей программы (пусть и с 1000000 строк кода), выполняющую конкретный ОГРАНИЧЕННЫЙ набор задач и не предусматривающую существования остального мира... :о)

Собственно, никаких особых предпосылок для изменения стиля мышления не было, была просто красивая идея... В те времена в нашей стране не было не только Интернет, но и... доступной литературы.
Может для вас это будет неожиданностью, но В ТЕ времена Интернета (с большой "И") не только в нашей стране, но и ТАМ не было...
А на счёт литературы... На Западе по этой теме тоже было не особо много литературы... В журналах специализированных появлялись статьи, сборники выходили. Но основная масса нашей братии была почти в том же положении. Могу даже взять на себя смелость заявить, что в конце 80 – начале 90 мы вдруг оказались даже несколько более "продвинутыми" по знаниям и наличию инструментария, как не удивительно это звучит...

Издавали очень мало, то что издавалось расходилось по «карточкам» (была такая система: издательства публиковали планы выпуска книг на следующий год, и в момент издания этих планов в некоторых магазинах можно было подписаться на книги, указанные в планах.
А что такого – прообраз заказов через Интернет... :о))))
Вы бы посмотрели на состав книг по программированию в районной библиотеке клуба пгт Екатеринославка Амурской области! :о)))))))


О появлении планов (обычно в ноябре) издательств знали заранее и к книжным магазинам задолго до открытия выстраивались очереди. Иногда везло...)
Ой страшилки какие!
Я спокойно приходил на второй этаж книжного магазина в ТЦ в Академе и заказывал, что мне надо...

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

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

Объект, как экземпляр класса, это типичная реализация, как и откомпилированный модуль (создаваемый/подгружаемый отдельно или в составе программы). И здесь нет противоречия.
Есть. А если у меня модуль – результат моего проектного решения, по которому в нём описаны объявления НЕ ОДНОГО класса?
Вы, кстати, забываете, что в расширяемых системах модуль (откомпилированный) просто ОБЯЗАН нести какую-то метаинформацию о своём содержимом... Дальше продолжать?

Но все же ООП и модульное программирование, конечно, не тождественны.
Конечно же нет. Модульное программирование – ОРГАНИЗАЦИЯ НА (программных) СИСТЕМ. ООП – ОРГАНИЗАЦИЯ СУЩНОСТЕЙ В ЭТИХ СИСТЕМАХ.

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

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

Но разговор о семантическом моделировании и принципах построения хороших классификаций... совсем другая тема.
Согласен.

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

класс обладает полиморфными свойствами (интерфейсами, если желаете).

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

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

и как замена колес влияет на изменение функциональности?

Б. Статическое (псевдо-динамическое) изменение функциональности
Данное изменение, тоже в реальности не является изменением функциональности

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

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

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

Ответ на »сообщение 4070« (AVC)
___________________________
Интрефейсы, случайно, не тот механизм, который Вы так упорно ищете?
Скорее всего – нет. Интерфейсы, являются просто ещё одним формализованным способом закрепления в тексте программы результата классификации при анализе и проектировании.

Но вот вам уже приводившийся мною пример.
Предположим, что у вас есть некая функция, сортирующая объекты "по возрастанию" (критерий зависит от задачи...)
Если вы пишете полностью законченное ("оконечное", "замкнутое") приложение, то, ПРИ СЛОЖИВШИХСЯ ПОДХОДАХ, вы обязаны реализовать в ваших классах, объекты которых будут передаваться этой функции некую функцию сравнения. Последняя требуется для работы рассматриваемой сортирующей функции.
Всё – ОК.
Но, если у вас расширяемая, модульная, ИМЕННО КОМПОНЕНТАЯ система и вы используете чей-то уже готовый модуль. В этом модуле генерятся объекты определённых типов, также предоставляющие нужную функцию сравнения для этого типа, но имеющую ДРУГОЕ ИМЯ.
Какие проблемы?! Тип из чужого модуля нам ОЧЕНЬ НУЖЕН. И мы решаем убить некоторое время на исправление всех имён аналогичных функций В НАШЕМ КОДЕ.
Компилируем и радуемся.
Да вот беда. Заказчик потребовал расширение функциональности.
Вы не забыли, что мы уже работаем в истинно компонентной системе? :о)
Мы узнаем, что у другого поставщика есть свой модуль, в котором есть поддержка элементов нужных нам типов. Мы находим этот модуль.
И тут вдруг выясняется, что – вот несчастье – ИМЯ ФУНКЦИИ СРАВНЕНИЯ в классе из второго модуля опять другое... Что делать? Обёртки писать – извращаться, свой класс писать?
Почему возникли такие проблемы? И почему в нынешних сложившихся подходах они не разрешимы без большого мозгового напряга и откровенно неизящных решений?
Потому, что изначально, априори, в языковых средствах реализации заложено требования прямого отображения леса классификации на лес наследования классов.
Потому, что требование на "совместимость" перенесли на глобальный уровень. От конкретики работы в конкретных местах обращения к конкретной функциональности.

Но подобных проблем в том же Лимбо и в помине нет. Нет, с переименованием там тоже ещё не всё решено, но там не нужно лишних построений для удовлетворения заявленным требованиям.

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

Ответ на »сообщение 4069« (hugi)
___________________________
>>>Предположим, у Вас есть две переменных X = 'abcd' Y = 3.345 и Вы хотите их сложить. Вы случайно не знаете, что даст сумма строки и вещественного числа?
Я встречал 3 варианта:
1) X+Y= 3.345
2) X+Y= 'abcd3.345'
3) ошибка выполнения
и каждый из них имеет свое обоснование.

>>>Да и вообще не все операции осуществимы над произвольными данными (к примеру деление строки на строку).
Пусть X=1,Y=0. Тогда операция X/Y неосуществима (при обычной семантике деления). Однако, типы к этому не имеют отношения.

Ответ на »сообщение 4078« (info21)
___________________________
а банальной необходимостью.
Вот.
Банальная необходимость -- твердая опора среди... идей.
Наверное, все же... не опора, а стартовая точка, то что заставляет задуматься...

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

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

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