Воинствующие дилетанты считают, что чем тут занудство разводить, лучше классиков читать:

D.L. Parnas
On the Criteria To Be Used in Decomposing Systems into Modules

http://www.acm.org/classics/may96/

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

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

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

Adding a new shape, an ellipse for example, simply means adding a module Ellipses to the system's library. No changes to the other modules are needed, in particular no recompilation. This implies that an extension is possible without requiring availability of the source text of the base.

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

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

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

Почему так много споров вокруг терминов?
Мы ведем борьбу с все возрастающей сложностью задачь. Для этого используются старые как мир приемы: разделение системы на части с минимизацией связей (в программировании - модули); классификация и унификация (в программировании - классы).
Я не понимаю, почему эти подходы упорно пытаются противопоставлять или сравнивать. Их необходимо сочетать.
to:  Сергей Губанов
Дайте, наконец, ОПРЕДЕЛЕНИЕ модуля (или модульной системы, что Вам удобнее). Раз уж Вы "четко понимаете их смысл". Иначе ваши утверждения невозможно принять или оспорить. Никто не может понять, в каком смысле Вы эти слова используете.

Ответ на »сообщение 3946« (Сергей Губанов)
___________________________


Да, EXE/DLL - модули расширения системы Windows. Да, их можно писать на всяких-разных языках. И что?


А то, что, согласно вашему определению модульного языка, как языка "оптимизированного для создания модульных систем", модульным может быть признан любой язык программирования, т.к. *.dll и *.exe можно одинаково легко писать на любом языке.

Ответ на »сообщение 3946« (Сергей Губанов)
___________________________

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

И назовите, пожалуйста, Ваше определение модульной системы, а то примеры Вы приводите, а по каким критериям именно эти системы а не какие-либо другие  попали в разряд модульных никому, кроме Вас, не известно!

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

Если брать определение модуля как компонента системы, то тогда и *.exe и *.dll, являясь компонентами всем известной системы :), подпадают под это определение. Но и то и другое можно писать на любом языке (хоть на ассемблере) и, следовательно, любой язык может называться модульным (критерий "оптимизированности" языка для написания модульных систем тут не проходит, т.к. вышеупомянутые объекты ОС Windows одинаково легко пишутся на любом языке).

Да, EXE/DLL - модули расширения системы Windows. Да, их можно писать на всяких-разных языках. И что?

В случае с Delphi можно сделать так, чтобы откомпилированные модули (unit) хранились в отдельных файлах и подгружались автоматически при обращении к ним -- всё упирается в среду исполнения.

Верно. Unit станет модулем не от того что внутри него что-то поменяется (внутренняя причина), а от того что появится соответствующая модульная система модулем которой он станет являться (внешняя причина!!!). Покуда модульной системы нет unit - не модуль.

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

Я и имел в виду наследование и полиморфизм у типов, а не у модулей. И в связи с этим хотел бы добавить, что я за классы ещё и потому, что они совмещают в себе свойства типа данных и, так сказать, единицы абстракции, заменяя тем самым две сущности на одну. Это удобнее.
Хотя, опять же, здесь возникает проблема видимости классов, и концепция модуля или пространства имён как средства инкапсуляции (хотя такая же проблема вознакает и в случае с модульными языками без классов типа Oberon -- всё зависит от позиции автора языка по вопросу: "Нужна ли нам инкапсуляция классов (модулей) или нет?").

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

Это аргументы для: Oberon-модуль vs. Класс. Наследование и полиморфизм, отличающие ООП от АТД, не упоминаются сознательно, т.к. в Обероне они есть.

Важный момент. Если мы говорим об Обероне, то наследования у модулей нет. Как нет у них и полиморфизма.

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

Ответ на »сообщение 3924« (Сергей Губанов)
___________________________


Ответ на »сообщение 3903« (hugi)
1) Концепция модуля базируется на концепции абстрактного типа данных.

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

Да, здесь я не прав. Концепция модулей появилась раньше концепции АТД, и АТД активно использует её в своих целях (инкапсуляция). Но поскольку речь шла о модулях в Oberon, где обе концепции прекрасно ужились, расширились и являются основополагающими, я позволил себе такую вольнось. Приношу извинения.

Однако мне непонятна Ваша трактовка модуля и модуля систем. Если брать определение модуля как компонента системы, то тогда и *.exe и *.dll, являясь компонентами всем известной системы :), подпадают под это определение. Но и то и другое можно писать на любом языке (хоть на ассемблере) и, следовательно, любой язык может называться модульным (критерий "оптимизированности" языка для написания модульных систем тут не проходит, т.к. вышеупомянутые объекты ОС Windows одинаково легко пишутся на любом языке).

Мне лично нравится классификация модулей, предложенная Русланом Богатырёвым. Ведь в Delphi, когда Вы пишите программу, Вы не можете использовать элементы модуля, которые модуль не экспортирует (ошибка компиляции). Т.е. на уровне языка Delphi поддерживает модули как средство инкапсуляции и абстракции. Т.е. Delphi -- модульный язык. Pascal (чистый) же, насколько я знаю, не позволяет разбивать текст программы на модули, тем самым ограничивая возможности инкапсулирования и абстрагирования. Pascal -- не модульный язык.

В случае с Delphi можно сделать так, чтобы откомпилированные модули (unit) хранились в отдельных файлах и подгружались автоматически при обращении к ним -- всё упирается в среду исполнения. В случае с Pascal тоже можно сделать так, что написанные на нём программы смогут использовать друг друга -- всё опять же упирается в среду исполнения (пример -- COM).

Всё, сказанное мной выше, примерно укладывается в схему Руслана Богатырёва, если я правильно её понял.

Ответ на »сообщение 3940« (Сергей Губанов)
___________________________

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

На примеры модульных систем я пальцем показывал, так что остается слово "оптимизированный" - его надо понимать как просто слово русского языка. Его можно заменить на "заточенный", "специально предназначенный".

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


Вот и пытаюсь хотя бы косвенно выяснить, что же вы понимаете под словами "модуль" и "компонент", которыми так свободно "жонглируете".

Как сказал бы в данном случае ASU, свободно жонглировать словами "модуль" и "компонент" мне удаётся потому, что я чётко понимаю их смысл. Вы же, пока, этот смысл только ищете.

Насчет ASU -- я уже обратил внимание и на глубину его анализа в преломлении к нашей дискуссии. Весьма показательно. Синтеза от него, думаю, вообще вряд ли удастся дождаться...

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

Если вы еще не поняли, это дискуссия, в которой сопоставляются разные точки зрения, разных людей, с разным опытом и разными привязанностями. А не технический форум, где пытаются найти однозначный ответ на конкретный технический вопрос.

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

Windows & Linux

*.DLL - модуль ОС Windows
*.SO - модуль ОС Linux

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

Оказывается, все до банальности просто, какие там высокие материи: Windows -- это модульная система, а DLL -- модуль.

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

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

Относительно Windows. Windows как модульная система состоит исключительно из модулей (DLL)? Т.е. кроме DLL в ней ничего и нет? Это серьезно? А если наблюдается что-то другое, то что это? Или в Windows есть другие модули, о которых вы не упомянули? Т.е. все, что в ней только можно выделить, уже и есть модуль?