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

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

Отсутствие в Обероне каких-сложных вещей типа механизмов управления много-много-модульными системами (как и concurrency) -- это не утверждение об их (механизмов) ненужности, а об их непонятости -- при том, что в существующем виде Оберон/КП позволяет без особого труда моделировать практически любые схемы организации.  Также как О/КП позволяет себя легко "достраивать" (AOS, Active BlackBox etc.)

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

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

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

Стало совсем интересно :) Я представил, как из системы выключается такая "системообразующая подсистема", как сервер БД. И никто этого не заметил. Или сервер БД не укладывается в ваше понятие "подсистемы"?

Вы будете смеяться, но мне довелось заниматься системой, для которой, мы сделали возможность "на горячую" перетыкать модули БД. Локальная/сетевая/никакой.

В случае "никакой" система сохраняла возможность работать с локальными файлами в XML. В принципе можно было сделать и автоматику, типа отваливается сетевая БД, клиент прозрачно переключается на локальную, даже не заметив этого :)))))))))

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

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

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

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

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

Стало совсем интересно :) Я представил, как из системы выключается такая "системообразующая подсистема", как сервер БД. И никто этого не заметил. Или сервер БД не укладывается в ваше понятие "подсистемы"?

Вы будете смеяться, но мне довелось заниматься системой, для которой, мы сделали возможность "на горячую" перетыкать модули БД. Локальная/сетевая/никакой.

В случае "никакой" система сохраняла возможность работать с локальными файлами в XML. В принципе можно было сделать и автоматику, типа отваливается сетевая БД, клиент прозрачно переключается на локальную, даже не заметив этого :)))))))))

Ответ на »сообщение 4156« (Илья Ермаков)
___________________________
Стоп. Прошу прощения. "Образует граф". Все верно. Граф, но ациклический направленный и иерархический.
Любая иерархия - это граф, но не всякий граф иерархия. Связи модулей на одном уровне (прямые или опосредованные), в общем случае и в Вашем примере, образуют направленный граф, в частном случае - иерархию.
Система делится уровни - здесь строго иерархическая структура.

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

Ответ на »сообщение 4152« (Stargazer)
___________________________
Пользуясь той же стилистикой, скажу: системная логика стога сена формируется на логике взаимодействия травинок. Иначе стог не был бы стогом.
Логику стога сможете раскрыть? Расскажите, мне интересно...

А вы... стог... сена видели? Для чего его делают... в курсе? Подумайте на... досуге.

Ничего себе. Летит самолёт, и вдруг у него отваливаются двигатели. Никто ничего не заметил, все продолжают лететь.
Всё чудесатее и чудесатее.
Если Вы не заметили, то повторю, что речь шла о нашей системе, а не о Вашем самолете. Ферштейн?.. «Блочный ремонт» без остановки для многих систем давно стал нормой... уважительного отношения к заказчикам/потребителям.

Стало совсем интересно :) Я представил, как из системы выключается такая "системообразующая подсистема", как сервер БД. И никто этого не заметил. Или сервер БД не укладывается в ваше понятие "подсистемы"?

Ответ на »сообщение 4157« (Axcel)
___________________________
В системах, к разработке которых я когда-то имел отношение (системы управление РВСН - НПО "Импульс"), конечный пользователь никогда, ни при каких обстоятельствах, не имел права (и не имел никакой возможности) менять логику без привлечения разработчиков.  А вот, операторы Чернобыльской АЭС имели, если не право то, по крайней мере, возможность.  Так что, системы бывают разные, соответственно всякие там "возможности" или "невозможности" надо специально продумывать и специально закладывать. Насколько удобны Обероны для разработки систем  со  подобными "возможностями/невозможностями" ? Думаю, что удобны.
Вы случайно или намерено смешиваете два совершенно разных понятия: возможности системы и права пользователей. Я никогда не призывал ко вседозволенности, но я категорически не приемлю решений, которые не могут работать без их "авторов"... это кормушка для топ вечно... голодных "франчайзи"...

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

.. Вместо FROM Math IMPORT Sin я бы предпочел неписать просто IMPORT Sin, а насчет From пусть болит голова у того, кто будет собирать из модулей систему - у него должен быть другой инструмент.


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

Чтобы я для всех внешних сущностей всегда писал From MyImportList, а в  MyImportList потом поставим каждому соответствующий модуль реализации. Только зачем повторять в десятках и сотнях строк From MyImportList?

Все равно нужно повторять в отдельных модулях описания интерфейса этого Sin.
"Зачем повторять" звучит как каприз.

Механизм, практически 1:1 аналогичный тому, что делает независимый линкер -- это сделать глобальную переменную для Sin, и заполнять ее из какого-нить Config или Setup, вызываемого при инициализации.

Короче, сия конкретная проблема ничтожна.

Предложение для адептов Oberon
Уважаемые адепты, мне импонирует ваше трепетное отношение к простоте и строгости, к введению и контролю продуманных формализмов. Безусловно, это дает большой... нет, очень большой... положительный эффект и с точки зрения читабельности текста программ, и с точки зрения надежности кода.
Давайте рассмотрим один из примеров того, за счет чего это достигнуто. Развитие и становление структурного программирования в значительной степени обязано формированию культуры структуризации (декомпозиции) кода. Подпрограммы дали возможность не только сократить трудозатраты на написание программ, за счет использования библиотечных подпрограмм (единожды написанных и отлаженных), но и... Подпрограмма локализует свой код, нельзя, не нарушая принципов структурного программирования, перейти на любой оператор подпрограммы, минуя ее заголовок. К следствие, резко сократилось количество связей внутри самой программы. И именно развитие методов декомпозиции дало возможность отказаться от пресловутого оператора перехода GoTo... Программы перестали напоминать «спагетти».
Но на уровне модулей... история вновь повторяется. Любой модуль может обратиться к любому другому модулю, надо только указать его в списке импорта, как в случае GoTo надо было только объявить метку, куда будет осуществлен переход. Пока модулей («операторов») в программе относительно немного отслеживать переходы не составляет большого труда, но... что происходит при увеличении их числа?.. Система может содержать тысячи модулей. Как управлять этим «хозяйством»? Как отслеживать связи («переходы»)? Не в этом ли причина того, что даже внесение небольших изменений в систему приводит к... рефакторингу всего и вся.
В чем корень того упорства, с которым вы отрицаете необходимость структуризации модулей и введение специальных механизмов контролирующих их взаимодействие? Согласитесь, что подпрограмма – это не отдельный оператор, это структура кода. Точно также, подпрограмма «помогает» программе структурировать код, кто должен помочь системе структурировать взаимодействие модулей.

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

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

И еще... в Вашем решении... Попробуйте изменить логику Server, не останавливая работу системы... Сможете? Нет... Вы получили «неотчуждаемое» решение... то есть, Вы стали рабом (заложником) своего собственного детища... Любое изменение требует привлечения разработчика.

В системах, к разработке которых я когда-то имел отношение (системы управление РВСН - НПО "Импульс"), конечный пользователь никогда, ни при каких обстоятельствах, не имел права (и не имел никакой возможности) менять логику без привлечения разработчиков.  А вот, операторы Чернобыльской АЭС имели, если не право то, по крайней мере, возможность.  Так что, системы бывают разные, соответственно всякие там "возможности" или "невозможности" надо специально продумывать и специально закладывать. Насколько удобны Обероны для разработки систем  со  подобными "возможностями/невозможностями" ? Думаю, что удобны.