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

Хорошо, прямой вопрос: класс -- это модуль? Да или нет?
Нет.

Что является модулем (на уровне исходных текстов) в модульной системе, реализованной исключительно на концепции класса? (Пусть для определенности будет Eiffel.)

Ответ на »сообщение 3848« (Руслан Богатырев)
Хорошо, прямой вопрос: класс -- это модуль? Да или нет?


Нет.

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

1. Модуль и компонент -- это одно и тоже?
4. (гаджет) Это компонент или нет?
5. А подгружаемый/выгружаемый модуль -- компонент?
6. Какой модуль нельзя назвать компонентом и какой компонент нельзя назвать модулем? Почему? Где проходит граница между модулем и компонентом?

Модуль - это термин. Компонент - это просто слово. Слово компонент можно использовать как душе угодно, например так: модуль - это компонент модульной системы.

3. Требование того, что модуль является динамически загружаемой/выгружаемой единицей исполнения, автоматически подразумевает наличие сущности "модуль" в среде исполнения. Так?

Естественно. Среда исполнения загружает и выгружает модули. Как она при этом может не знать что такое модуль? Не ясен смысл вопроса.

2. Требование того, что модуль является единицей компиляции, автоматически наличие сущность "модуль" в языке программирования. Так?

Модуль пункта 2 и модуль пункта 3 -- это один и тот же модуль в одном и том же виде?

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

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

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

К чему же лукавить и уходить от ответа.

Хорошо, прямой вопрос: класс -- это модуль? Да или нет?

Ответ на »сообщение 3845« (Руслан Богатырев)
Покажите пальцем на компонент модульной системы (который класс) и назовите его модулем.

Не который и не класс.

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

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

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

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

Сергей, в »сообщение 3783« я задал вам несколько вопросов по модулям и компонентам, но, к сожалению, не увидел ответов (возможно, плохо смотрел).

Они вас слишком озадачили или же столь несущественны, что недостойны внимания?

P.S. Формулировку п.2 лучше смотреть по п.3. А то явно нарушено согласование слов. Хотя мысль, думаю, понятна.

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

Просто рассказываем что такое модульная система (она первична), а потом показываем пальцем на её компонент и говорим, что компонент модульной системы называется термином "модуль" (модуль - вторичен, модульная система - первична).

Да, здорово вы следите за аргументацией. Ничего не скажешь.

Покажите пальцем на компонент модульной системы (который класс) и назовите его модулем.

Или вы хотите сказать, что системы, построенные исключительно на концепции класса, нельзя ни при каких условиях считать модульными?

Теперь скажите, что класс и модуль -- одно и тоже. А если не одно и то же, то объясните, чем они все же отличаются. Что мы говорим о модулях, которые бывают, как минимум, двух видов -- модули и классы.

Т.е. модуль ::= модуль | класс.

Замечательное рекурсивное определение. И главное, очень полезное в работе.

Прежде чем продолжить дальше размышления относительно модулей и классов (надеюсь к Java мы скоро вплотную подойдем), несколько отступлений.

Вспомнил об одной из книг, которую хотел бы порекомендовать для пристального изучения с точки зрения анализа возможностей модульного программирования. Речь идет о книге "Конфигурации программ. Рецепты безболезненных изменений" (1994). В 1999 г. вышла ее пересмотренная редакция под названием "Расширяемые программы".

Автор книги -- М.М. Горбунов-Посадов, д. ф.-м. наук, заведующий сектором инструментальных средств конструирования программ Института прикладной математики им. М.В.Келдыша РАН ( http://www.keldysh.ru/dpt_19/gorbunov/ )

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

Для затравки -- небольшая выдержка:

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


Здесь ключевым понятием является "безболезненное расширение". Что это такое и как этого можно достичь? Именно этим вопросам и посвящена книга Горбунова-Посадова.

Ответ на »сообщение 3842« (Руслан Богатырев)
1. Модуль -- это сущность, которая наряду с классом относится к модульной категории.

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

2. Модуль имеет, как минимум, две формы -- в языке и в среде исполнения. Будем называть их соответственно языковой модуль (исходный текст) и операционный модуль (бинарная форма).

Похоже на то, что масса бывает инертная и гравитационная, но на самом деле они одинаковы.

3. Модуль принципиально отличается от класса тем, что он не является типом, порождающим (специфицирующим) значения.

Для того чтобы понять что такое модуль не нужны понятия ни класса ни типа. Следовательно упоминать о них не надо вообще.

Некоторые выводы по вчерашней дискуссии.


1. Модуль -- это сущность, которая наряду с классом относится к модульной категории.

2. Модуль имеет, как минимум, две формы -- в языке и в среде исполнения. Будем называть их соответственно языковой модуль (исходный текст) и операционный модуль (бинарная форма).

3. Модуль принципиально отличается от класса тем, что он не является типом, порождающим (специфицирующим) значения.

4. Модуль, как и класс, характеризуется капсулой и интерфейсом.

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

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

7. Между модулем и компонентом нельзя ставить знак равенства (в противном случае от одного из понятий можно смело отказаться). Выявление расхождений между модулем и компонентом пока не проводилось.


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

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

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