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

У нас есть два модуля A и B. Модуль A содержит внутри себя счетчик обращений (целочисленная переменная, сбрасываемая в 0 в блоке инициализации модуля). Доступ к счетчику осуществляется через экспортируемую процедуру без параметров с именем Inc. Модуль B импортирует процедуру A.Inc, однократное обращение к которой осуществляется в экспортируемой процедуре B.Do (в первом же операторе процедуры Do).

Загружаются оба модуля. Несколько раз вызывается B.Do. Очевидно, что счетчик в A отличен от нуля. Далее в этой ситуации рассмотрим несколько вариантов (взаимоисключающих друг друга).

1. Выгружается модуль A и загружается снова. Счетчик в A равен нулю?
2. Выгружается модуль B и загружается снова. Счетчик в A равен нулю?
3. Выгружается модуль A, затем модуль B, загружается модуль A, затем модуль B. Счетчик в A равен нулю?

Как это регламентируется языком программирования (Оберон и Компонентный Паскаль)? Что будет соответственно в ETH Oberon и в BlackBox?

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

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

Проблемы усугубляются вот еще чем.

»сообщение 4039«
Эти системы расширяются модулями - единицами исполнения. Модули динамически загружаются и выгружаются. Модули с одинаковым интерфейсом взаимозаменяемы.

Можно ли сделать модуль (единицу исполнения) на языке Си? Можно.

Могут ли такие операционные модули динамически загружаться и выгружаться? Да. Этого можно добиться, реализовав соотв. среду поддержки (run-time), даже не отвлекаясь на особенности той или иной ОС.

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

Могут ли такие операционные модули с одинаковым интерфейсом в рамках данной среды поддержки быть взаимозаменяемы? Нет никаких сомнений.

Последний вопрос: можно ли такие операционные модули писать на языках, отличных от Си, например, на ассемблере? Безусловно.

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

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

А в Обероне нельзя достичь этого эффекта при помощи композиции объектов?

Достичь можно по-разному. Оберон -- это же конструктор. Здесь два аспекта:

1. Нюансы поддержки нескольких иерархий через границы модулей

2. Что есть контекст и зачем вообще нужен?

ОО-системы характеризуются децентрализацией управления, при этом данные, отвечающие в совокупности за состояния системы и ее частей (элементов), "размазываются" во всем объектам.

Что в такой ОО-системе можно считать ее состоянием? Совокупность значений всех без исключения полей всех без исключения объектов? Как с этим можно работать? Как извне (или изнутри) осуществить (проконтролировать) переход системы из одного состояния в другое? Как идентифицировать текущее состояние? Есть ли оно вообще?

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

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

В общем-то, моя реплика относительно третьего параметра была вызвана обоими упомянутыми аспектами.

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

Ответ на »сообщение 4002« (info21)
___________________________
Речь идет не об архитектуре языка, а об архитектуре системы.

Конечно, именно про это мой вопрос.

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

Проверил, действительно: КП был объявлен с таким именем уже в 1997. Приношу свои извинения. Как летит время.

Но что Гуткнехт был первым -- пока не опровергнуто.

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

А теперь представим, что мы добавим третий параметр -- контекст сообщения.

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

А в Обероне нельзя достичь этого эффекта при помощи композиции объектов? Наличие универсальноко обработчика как раз и позволяет объекту-обертке, знающему контекст, модифицировать сообщение, а значит и обработку сообщения, необходимым образом. Что характерно динамически.

Ответ на »сообщение 4019« (Как слышно? Прием!)
___________________________
Всегда восхищался свободой полёта мысли ASU!
Это ошарашивает как левостороннее движение в Таиланде.
В одном сообщении: "Передать смысл... нельзя".
Далее: "Необходимо... дабы в них (рассуждениях) был смысл.
Но смысл сначала надо открыть". И тут я в мозговой панике.
Я так не могу. Что-то внутри мешает. Надеюсь мозги.
Движение в Тайланде «ошарашивает» само по себе, даже без учета сторонности. По узкой улице ведут слона... медленно... за ним едет лимузин (стоимостью не менее $100 000). Из боковой улицы внезапно вылетает мотороллер, врезается в переднюю ногу слона. Слон шарахается назад... из лимузина достают... пассажиров. Движение в Тайланде...
А мозговая паника – это... полезно (особенно натощак... нет, без шуток).

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

Без комментариев.

Ответ на »сообщение 4028« (Горбунов-Посадов)
___________________________

Модуль – выделенная по тем или иным мотивам часть программы.

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

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

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

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

Что вытекает из приведенного определения? Программа -- это модуль. Любой фрагмент (часть) программы -- это модуль. Любой фрагмент фрагмента -- тоже модуль.

При этом в Обероне нет программы, нет даже выраженного главного (головного) модуля, есть только равноправные модули. Как это согласуется с принятым определением? Увы, с большим трудом, если согласуется вообще.