Ответ на »сообщение 5085« (Стэн)
___________________________

Да, приходится признать, что активные объекты с компонентным ПО плохо совместимы.

А при чём здесь модульность-то? Можно делать компонентное ПО на языках, где нет понятия "модуль", так же как и модульные языки для создания некомпонентного ПО...
Модульность и компонентность - независимые друг от друга вещи...

Ответ на »сообщение 5084« (Geniepro)
___________________________
>>> Это какие такие задачи? Интересно, где это может помешать модульность?

Вот здесь, например: »сообщение 5055«
>>> Да, приходится признать, что активные объекты с компонентным ПО плохо совместимы. После долгих размышлений прихожу к тем же выводам, о каких говорили Вы.
>>> См. http://forum.oberoncore.ru/viewtopic.php?p=7598#p7598 - от этого сообщения и ниже.

Далее, всем известный шаблон проектирования IoC. Как я уже писал:
http://stanonwork.blogspot.com/2007/08/inversion-of-control.html
Необходимым условием наличия IoC является односторонняя зависимость сущности A от B, и соответственно множества функций Fa от Fb. Ведь только при наличии такой зависимости невозможен явный (прямой) вызов функции z принадл. Fa из функции y принадл. Fb. А так как прямой вызов невозможен, то такой вызов возможно осуществить только косвенно, каким-то образом передав адрес функции z в функцию y.

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

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

Ответ на »сообщение 5083« (Стэн)
___________________________

задачи, которые не очень-то дружат с модульностью?

Это какие такие задачи? Интересно, где это может помешать модульность?

Ответ на »сообщение 5082« (Geniepro)
___________________________
>>> В-общем, системы 24х365...

Хорошо. Вернувшись к статье "Секреты модульных систем" можно узнать, что основным физическим воплощением модульных идей является язык Oberon (или даже правильно говорить Oberon-технология).
Совсем недавно мы с Ильей здесь обсуждали, что компонентность плохо дружит и с IoC, и с мониторами, и с Активными Объектами...

Насколько справедливым будет утверждение о том, что системы 24x365 - это и есть ниша применения Oberon-технологии с присущей ей динмамической модульностью? И что, возможно, на Oberon и можно создавать персональные текстовые редакторы, но лучше подобрать для этого другой инструментарий, так как при создании программ, допускающих остановку и перезапуск на передний план, по важности, выходят задачи, которые не очень-то дружат с модульностью?

Ответ на »сообщение 5078« (Стэн)
___________________________

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

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

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

В-общем, системы 24х365...

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

То есть реально работающего ничего еще нет? BlackBox потенциально много чего позволяет...
А вот в стандартной поставке все приходится делать по-старинке, вручную :(

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

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

Если Вам тах хочется, отслеживайте вручную :)

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

BlackBox позволяет, вот как раз занялись таким "выгружатором" :)

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

Если Вам тах хочется, отслеживайте вручную :)

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

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

>>> А как "end-user" я могу задать вполне резонный вопрос - а зачем это программу останавливать? Это наверное, такой шаманский приём... А, вы по-другому не умеете? Ну-ну.

Вот как раз об это я и упомянул - не предлагать... :-)
Вопрос стоял так: класс задач, в которых не прикольно, а необходимо менять программу без ее остановки.
Я же как "end-user" выключаю компьютер, когда иду спать... Все равно останавливать приходится. А частота смены plug-in'ов в моих программах реже, чем выключения на ночь... Так что от меня не убывает, когда раз в месяц приходится перезапустить программу при добавлении "модуля"...

Ответ на »сообщение 5076« (___)

Разработка.


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

Если Вам тах хочется, отслеживайте вручную :)