Ответ на »сообщение 4172« (AVC)
___________________________
>> Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...

> Может, если вызываемая подпрограмма экспортирована другим модулем.
Конечно, экспортирована (я же указал, что экспорт и импорт обоих модулей правильно оформлены)... Значит может... Тогда придется долго-долго убеждать программистов в том, что... делать-то они это могут... но это не хорошо... и не забывать пальчиком погрозить :)

А что тут такого уж неприятного?
С этим живем... и неплохо живем... :)
Кто-то (не Вы) говорил мне про каменный век... Там тоже жили и неплохо... наверное...

Для того в Обероне и модули, а не отдельные программы-процессы, чтобы можно было регулировать общение "напрямую".
А иначе -- UNIX с "пайпами"...
Да, уж лучше UNIX... для меня по-крайней мере...
Тогда у меня остался только один вопрос: «Почему адепты Oberon в одном случае отстаивают простоту и строгость, а в другом аналогичном случае – сложность и халатность? Когда же им верить?»...

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

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

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


Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...
Нет, не может. Порядок доступа определятся модулем.

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

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

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

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

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

1. Возможности -- это перечень (список, структура) имен сущностей (с указанием/без указания их атрибутов).
2. Потребности -- это обращение к сущностям по именам (с указанием/без указания атрибутов и их значений).

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

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

Теперь конкретизируем язык. В языке Оберон/КП:
1. Имена сущностей с атрибутами декларированы/описаны в интерфейсах (спецификациях, DEFINITION).
2. Реализации сущностей выполнены/объявлены в реализациях (модули, MODULE).
3. Категорически запрещается обращаться к внешним сущностям, минуя интерфейсы (пресекается языком, на уровне компилятора).
4. Связь блока с именем_сущности может выполняться как на этапе компиляции (локальные сущности модуля), так и на последующих этапах (любая внешняя сущность).
5. Связь интерфейса с реализацией_сущности может выполняться как жестко (один интерфейс -- одна реализация), так и гибко (один интерфейс -- несколько реализаций). Связь специфицируется на этапе компиляции, а воплощается на последующих этапах (любом из них).

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

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

Еще какие-то вопросы остались?

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

Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...

Может, если вызываемая подпрограмма экспортирована другим модулем.
А что тут такого уж неприятного?
С этим живем... и неплохо живем... :)
Для того в Обероне и модули, а не отдельные программы-процессы, чтобы можно было регулировать общение "напрямую".
А иначе -- UNIX с "пайпами"...

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

О/КП позволяет себя легко "достраивать" (AOS, Active BlackBox etc.)

Мои извинения И.Ермакову за "легко".
Все, конечно, относительно.
Но 4 человеко-месяца, даже если человек талантлив, для подобной достройки -- это, все-таки, скорее "легко" в подобном контексте.

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

Ответ на »сообщение 4166« (info21)
___________________________
И для того, чтобы, наконец, сформулировать эту очевидную мысль, нужно было ломиться зиллионом постов??
Хм?.. Посмотрите на »сообщение 3856« , разве там не эта мысль была сформулирована?..

Хм.. Это называется "сформулирована"?..

Ответ на »сообщение 4168« (AVC)
___________________________
Аналогия с Фортраном не вполне ясна.
К обероновскому модулю можно обратиться только через интерфейс и никак иначе. (Никаких "дополнительных точек".)
У нас разные точки/масштабы рассмотрения... Ну, не нравится сравнение с Фортраном, не смотрите на него... я же не настаиваю. Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...

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

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

Аналогия с Фортраном не вполне ясна.
К обероновскому модулю можно обратиться только через интерфейс и никак иначе. (Никаких "дополнительных точек".)
Оберон имеет средства ограничения "буйства жизни" :) не только на уровне подпрограмм (структурное программирование), но и на уровне модулей (модульное программирование; среди таких средств: обращение только через интерфейс модуля, ацикличность (иерархичность) модульной структуры и т.д.).
Сейчас я хочу обратить внимание на один момент.
Надежность системы зависит от соблюдения заложенных в нее инвариантов.
(Одна из любимых цитат оберонщиков: "Надежность -- это инварианты, принятые всерьез".)
За инварианты внутри модуля отвечает разработчик модуля, и никто другой.
В частности, именно он закладывает возможность/невозможность замены какого-либо предоставляемого модулем сервиса "на лету".
Это примерно то же самое, что и разница между переменной и константой.
Иногда такая замена допустима, иногда нет.

Ответ на »сообщение 4166« (info21)
___________________________
И для того, чтобы, наконец, сформулировать эту очевидную мысль, нужно было ломиться зиллионом постов??
Хм?.. Посмотрите на »сообщение 3856« , разве там не эта мысль была сформулирована?..