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

2) Модуль может не содержать процедур:

В принципе это можно свести к public-полю объекта. А вот то, что модуль может просто экспортировать типы, уже поинтереснее в качестве иллюстрации.

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

Вся компиляция идет по очереди. Так что не понятно что значит компилировать вместе???

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

В случае Оберона сначала определяется зависимость модулей по импорту (тут общий импорт в модуле, без разделения на DEFINITION-импорт и IMPLEMENTATION-импорт), затем вычленяются наборы модулей (в соответствии с топологической сортировкой), по степени зависимости друг от друга (сначала те, которые ни от кого не зависят, затем те, кто от них и так далее). Вот их компиляцию теоретически и можно распараллелить. Но можно для Оберона пойти по другому пути, сведя задачу к Modula-2 за счет первичного выделения интерфейсов (см. дальше).

В Modula-2 (где DEFINITION отделен от IMPLEMENTATION и есть два импорта), напр., можно было бы сначала оттранслировать DEFINITION-модули (стандартным последовательным образом, опять-таки с учетом топологической сортировки), а затем использовать полученный набор SYM-файлов (результат трансляции DEFINITION-модулей) для параллельной компиляции IMPLEMENTATION-модулей (здесь порядок уже вообще не важен).

При этом стоит учесть, что некоторые системы программирования для Modula-2 обходятся без генерирования SYM-файлов (формируя их на лету и храня в памяти). Так что на второй фазе требуется лишь доступа к общей памяти при параллельной компиляции других модулей.

Ответ на »сообщение 3724« (al_mt)

Можно ли в рамках нашего диалога считать, что модуль - это такой объект (экземпляр класса), который содержит только методы и не может "размножаться"?

1) Модуль - не экземпляр чего-то. Каждый модуль уникален.
2) Модуль может не содержать процедур:

MODULE X;

  VAR a*: INTEGER;

END X.

А почему Вы этого не знаете?

Ответ на »сообщение 3726« (al_mt)
Я, всего навсего, хочу сказать, что по моему мнению, компилировать разные программные модули можно и вместе

Непонятно, компилировать вместе это как?

Пусть модуль Б импортирует модуль А. Для того чтобы скомпилировать модуль Б нужно иметь исходный текст модуля Б и (символьный) бинарный файл модуля А, который можно получить только скомпилировав модуль А. Для компиляции модуля Б исходный текст модуля А не нужен.

То есть сначала кто-то где-то компилирует модуль А. Потом он даёт нам его символьный бинарный файл. Затем мы у себя компилируем модуль Б, не имея исходного текста модуля А.

Вся компиляция идет по очереди. Так что не понятно что значит компилировать вместе???

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

Можно ли в рамках нашего диалога считать, что модуль - это такой объект (экземпляр класса), который содержит только методы и не может "размножаться"?

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

Выберите время и почитайте про модульное программирование. А еще лучше -- изучите каноническую Modula-2. Глядишь, польза будет.

Ответ на »сообщение 3725« (Владимир Лось)
___________________________
В приведённом определении сказано "программный модуль программируется, компилируется и отлаживается отдельно от других модулей". Я, всего навсего, хочу сказать, что по моему мнению, компилировать разные программные модули можно и вместе, они от этого не становятся одним и не перестают быть программными модулями :)

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

Другое дело, что здесь зашла речь "Модули - без ООП!" с намёком, что без ООП-то лучче :)

Ответ на »сообщение 3720« (al_mt)
___________________________
Я бы сказал, что раздельная компиляция не обязательна
Пардон, разрешите поинтересоваться, мы о программировании компонентов?...

И как следствие не вижу ни малейшего противоречия между модульным и ОО программированием.
В рамках ЧЕГО? На каком уровне представления системы? На коком этапе её развития, как проекта?

Ответ на »сообщение 3721« (Руслан Богатырев)
___________________________
Можно ли в рамках нашего диалога считать, что модуль - это такой объект (экземпляр класса), который содержит только методы и не может "размножаться"?

Ответ на »сообщение 3721« (Руслан Богатырев)
___________________________
Ага. Кажется понял.
Вы хотите сказать, что если есть модуль, который на самом деле - объект (класс?), то возможность унаследоваться от него является источником ошибок, которых не может возникнуть в случае классического модульного программирования?

P.S. ...полиморфизм пока отложим

Ответ на »сообщение 3718« (Сергей Губанов)
___________________________
Кстати, а откуда взялся термин "кошачий пастух"?
http://www.books.ru/shop/books/309225
Спасибо.

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