Мне кажется, чтобы говорить о классах и модулях не слишком абстрактно, полезно иметь перед глазами хорошие примеры тех и других.
С этой точки зрения, мне думается, было бы полезным, если бы каждый (еще раз) перечитал 12-ю главу (Object-orientation) из старой книги Рейзера и Вирта "Programming in Oberon. Steps beyond Pascal and Modula", особенно -- раздел 12.4 (Objects and modules).
Я никакой особой мысли сейчас не имею в виду. Просто думаю, что этот текст был бы полезным фоном наших рассуждений.

Читаю сейчас
Active Oberon Language Report - Patrik Reali - October 27, 2004

Почему в описании грамматики вообще не упомянуты конкретные модификаторы блока - такие слова как EXCLUSIVE, ACTIVE, и т. п.?

Там написано:

StatBlock = BEGIN [‘{’IdentList‘}’] [StatSeq] END.
IdentList = IdentDef {‘,’ IdentDef}.
IdentDef = ident [‘*‘|’-’].


Таким образом, эти слова заявляются как идентификаторы.

Разве это идентификаторы? Не должны ли это быть ключевые слова?

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

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


Браво!

Ответ на »сообщение 3810« (Сергей Перовский)
___________________________
... Придется различать два понятия модуля: единица компиляции и единица загрузки.
... Мне лично удобнее самому делить проект на единицы загрузки, а их в свою очередь на единицы компиляции. ...
Уважаемый Сергей, всё дело в том, что вам так удобнее просто потому, что подлежащая система НЕ ПОЗВОЛЯЕТ поддерживать единство понятий модуля. Собственно, мне потому и нравится, например AOS/bluebottle, что на структуру модулей компиляции/загрузки (системного ресурса/понятия ОСи), я вполне логично и естественно могу отобразить структуру модулей как высокоуровневых "компоновочных" понятий проекта... То есть мне не нужно ИСКУССТВЕННО разделять эти понятия модуля. Получается, что сами язык реализации и ОСь помогают поддерживать закрепление проектных решений...

Немного поторопился с поздравлениями. Пока побудем дома... :о) Главное - не пришлось бы новый год в пути встречать!!! :о(

Ответ на »сообщение 3870« (Cardinal)
___________________________
Так вот, после команды Partitions.Create IDE1#01 101MB ~ в System.Log пишет "Specified partition is not free". Этот раздел IDE1#01 до установки "бутылки" я форматировал в Windows XP для FAT32, поэтому "бутылка" на команду Partitions.Show ~ показывает для этого раздела Win95/Win98.
Пардон, а вы его форматировали родным форматом Native Oberon?
...следующие команды бессмыслены :(
...

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

В COP, компонент - это термин, а что это такое определено у его автора - Клеменса Шиперского. Чтобы отличать модульные системы не использующие ООП от модульных систем с ООП, Шиперский назвал вторые - компонентными системами. Только и всего.

Верно ли я понял, что по Шиперскому (в вашем изложении) система Oberon System 3 не является компонентной?

Ответ на »сообщение 3874« (Сергей Перовский)
___________________________

Спор принимает религиозный характер.
Что и как называть, вопрос не самый главный.
Каждый имеет право сказать: в рамках моей Теории я буду понимать под модулем вот что, и вот какие утверждения я готов для ЭТОГО модуля доказать.
Вот только никто ничего ДОКАЗАТЬ не торопится...

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

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

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

Никакой религии. Просто разные взгляды, которые и выявились в ходе дискуссии.

Бога нет - сказал Остап,
Есть, есть - сказали ксендзы...

Спор принимает религиозный характер.
Что и как называть, вопрос не самый главный.
Каждый имеет право сказать: в рамках моей Теории я буду понимать под модулем вот что, и вот какие утверждения я готов для ЭТОГО модуля доказать.
Вот только никто ничего ДОКАЗАТЬ не торопится...

Пожалуй, впервые я столкнулся с понятием модуля в языке Аналитик (ПЭВМ МИР-2). Не было еще понятия файла, а модули были. Программа состояла из отдельных текстовых единиц (Информативы начинались ключевым словом ПУСТЬ, а Директивы - ключевым словом ВЫПОЛНИТЬ). Эти текстовые единицы могли ОТЧУЖДАТЬСЯ от программы с целью использования в других проектах. Они могли грузиться с одной перфоленты или с разных, все вместе или по мере необходимости. При этом они не были единицами компиляции по простой причине. Это был интерпретатор. Причем аппаратный. Этакий интерпретатор на транзисторах.
Я это к чему. Если мы рассматриваем язык - то речь идет всего на всего о правилах оформления текстов и выделении текстовых единиц. Текст делится на отдельные САМОСТОЯТЕЛЬНЫЕ тексты.
Целью является упрощение создания и понимания отдельных текстов и их повторное использование.
Если мы рассматриваем операционную среду, то там мы имеем дело с совсем другой целью: модульная загрузка призвана экономить оперативную память минимизируя дублирование загруженных текстов. Значит, в модули имеет смысл выделять только функции, которые встречаются во множестве задач, а значит программ. Ну, так загляните в SYSTEM32. Очень хочется почистить, слишком многие разработчики устанавливают туда свои модули, считая, что они имеют всемирно историческое значение.

Ответ на »сообщение 3871« (AVC)
___________________________
>>>Я так понимаю -- компьютеры у Вас долго не задерживаются. :)
Когда лет тридцать назад кто то из корифеев заявил, что со временем стоимость ПО будет относится к стоимости компьютера, как стоимость товара к стоимости упаковки, все вежливо посмеялись. Это время наступило.
Если заказчик доверяет кому то разработку серьезной программы, то такую мелочь, как закупка оборудования он уж должен доверять :)

>>>Если Вам будет интересно, то вынлю указанные главы.
К сожалению времени сейчас на чтение тостых книжек нет, тем более на английском :)
За предложение спасибо.

Вашей логике можно только позавидовать.

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

Р.Б. Покажите пальцем на компонент модульной системы (который класс) и назовите его модулем. Или вы хотите сказать, что системы, построенные исключительно на концепции класса, нельзя ни при каких условиях считать модульными?

С.Г. Не который и не класс. Классу можно дать внутреннее определение.

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

С.Г. Нет.

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

С.Г. Ничто. Дырка от бублика.

Р.Б. Ну вот, наконец, выяснили. Т.е. модульная система есть. Язык, на котором реализована, есть. Компонент (тот, который слово) у системы есть. Пальцем показывать приходится на дырку.

С.Г. Таких примеров масса: язык - не модульный, а модульные системы на нём создают. Мучаются, колются, плачут, но создают. Например, COM-программы на Си тоже ведь пишут, хотя в Си нет ни модулей, ни объектов...

А теперь сначала:

1. Компонент любой модульной системы называется термином "модуль".
2. Модульные системы могут создаваться не на модульных языках.
3. Модульные системы могут создаваться на языках, работающих только на концепции класса.
4. Класс не является модулем.
5. В модульных системах на основе классов нет модуля на уровне исходных текстов (дырка от бублика). При этом они являются модульными и в них должен быть модуль.

Вывод: модуль (в понимании С.Г.) не является понятием, воплощаемым на уровне исходных текстов. Что и требовалось доказать.