>>> расширение Блэкбокса моделью распределенных перманентных объектов.

Интересно. А можно пошире задачу описать? В частности, почему перманентных?

У меня складывается ощущение, что если объекты связаны циклически,
то они должны иметь существенную динамическую составляющую.
И даже, возможно, наоборот. Пример - триггер. Там заведены выходы
на вход - в результате получаем память.
Если статика - полезай на дерево. Чисто вход-выход.

Ответ на »сообщение 1211« (Илья Ермаков)

В .NET точно так же. Чтобы Микрософт в следующей добавила метод в какой-либо из стандартных уже документированных классов Framework - и помыслить невозможно, все существующие в мире сборки у всех разработчиков потребуют перекомпиляции...

Это не так.

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

Тут Интел твёрдой рукой ведёт всех в светлое будущее.
Что скажете, уважаемые коллеги, по поводу будущего Оберона в эпоху параллелизма? :)

http://www.computerra.ru/focus/298532/

Цитата:
"Руководитель отдела маркетинга и развития в подразделении Intel Software Development Products Джеймс Рейндерс уверен в том, что в будущем разработчики ПО столкнутся с огромными изменениями и "через десять лет, глядя в прошлое мы будем поражены тем, как изменился подход к написанию программного кода. Параллелизм станет всеобщим явлением".

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

>>>Закладывать ... принцип "главное ввязаться в сражение"
>>> и затачивать под это инструмент - неправильно.

Затачивать инструмент всегда правильно :)

"Кто кивер чистил весь избитый,
Кто штык точил, ворча сердито,
Кусая длинный ус".

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

А вот построение моделей одной за другой по принципу
"про всё, что здесь только что говорили - наплевать и забыть,
а теперь слухай сюды" - роскошь и разбрасывание ресурсами.
Так сказать "пораскинем мозгами" :)


>>> А вот возможность отобразить иерархию предметной области,
>>> это критически важно.

Ну-ка, постройте иерархию (дерево) "камень-ножницы-бумага".

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

Ответ на »сообщение 1210« (Сергей Перовский)
___________________________
Вы абсолютно правы касательно "криминала" для системного программиста и приемлемости для прикладного. И касательно Дельфи Вы тоже правы.
Просто среды разработки Оберонов, даже работая поверх другой ОС, являются мини-операционными системами. И модуль с этой точки зрения - не чать вашего монолитного проекта, а отдельное "приложение", которое может распространяться в т.ч. и без исходных кодов - кто будет делать full-rebuild? Поэтому менять интерфейс стандартных библиотек среды недопустимо в принципе. В .NET точно так же. Чтобы Микрософт в следующей добавила метод в какой-либо из стандартных уже документированных классов Framework - и помыслить невозможно, все существующие в мире сборки у всех разработчиков потребуют перекомпиляции...

Ответ на »сообщение 1207« (Илья Ермаков)
___________________________
>>>По поводу VCL - насколько я помню, в базовые классы визуальных компонент новые поля/методы добавляла периодически сама Borland, в результате чего при переходе на новую версию требовался full-rebuild...
Я понимаю, что для системного программиста отсутствие обратной совместимости самый большой криминал.
Прикладники относятся к этому по другому. Поскольку на собственно кодирование приходится на порядок меньше трудозатрат, чем на анализ задачи, даже полное перепрограммирование при переходе на другую библиотеку, среду или платформу не представляется катастрофой.
Есть байка (не знаю насколько правдивая) про ловлю обезьян при помощи сосуда с зерном: обезьяна запускает туда руку, хватает зерно, а вытащить сжатую в кулак руку не может. Зачастую программисты, которым жалко переписать часть кода, напоминают мне эту обезьяну. Время от времени нужно менять ИДЕОЛОГИЮ проекта, когда класс решаемых задач становится заметно шире, чем тот на который расчитывали заранее. А уж full-rebuild вообще операция естественная.
Если бы Борланд поддерживал полную обратную совместимость на уровне модулей, Дельфи давно забыли бы, как очень запутанный и крайне неудобный продукт.
Успех Дельфи как раз показывает разумность регулярной ревизии дерева классов при сохранении общей структуры.

Ответ на »сообщение 1207« (Илья Ермаков)
___________________________

Ответ на »сообщение 1206« (Сергей Перовский)
___________________________
По поводу VCL - насколько я помню, в базовые классы визуальных компонент новые поля/методы добавляла периодически сама Borland, в результате чего при переходе на новую версию требовался full-rebuild...

Ну, полный ребилд там требовался не поэтому - просто dcu-файлы от разных версий не совместимы.

Ответ на »сообщение 1206« (Сергей Перовский)
___________________________
Да вот хотя бы составные документы - для внедренных отображений модули должны быть подгружены динамически в момент открытия документа. Следовательно, графическая часть Framework должна быть построена так, чтобы поддерживать динамическое расширение.
Именно поэтому на VCL реализовать аналог составных документов BlackBox нельзя, даже если ядро Дельфи "научить" динамически загружать модули. Можно, конечно, использовать внешнюю объектную модель типа ActiveX/OLE, но тут уже VCL будет ни при чем...

Ответ на »сообщение 1206« (Сергей Перовский)
___________________________
По поводу VCL - насколько я помню, в базовые классы визуальных компонент новые поля/методы добавляла периодически сама Borland, в результате чего при переходе на новую версию требовался full-rebuild...

И отсутствие полноценного наследования с виртуальными функциями это существенно.
Отсутствие где? В Оберон-2 и Компонентном Паскале есть наследование и виртуальные функции. Самые нормальные. Просто ключевого слова class нет. Да плюс к тому же компилятор умеет отлавливать некоторые ляпы при введении некоторых методов в иерархию, за счет модификаторов NEW/EXTENSIBLE.
Нужно "отобразить иерархию предметной области" - отображайте, как обычно.
Речь идет о том, что BlackBox Framework спроектирован на мелком, иногда исключительно интерфейсном наследовании. И спроектирован очень удачно. В частности, использование методов HandleMessage и типов сообщений позволяет обходиться без уймы методов и безболезненно расширяться без переопределений интерфейсов. И такая идеология для системного программирования очень удачна.

"Возможность подгружать/выгружать модули по мере надобности? Я не уверен, что это так важно."
Для меня - важно. Потому что моя сфера интересов - СУБД и распределенные приложения, а одно из направлений работ - расширение Блэкбокса моделью распределенных перманентных объектов. И в моем случае динамическое связывание во всех аспектах жизненно важно.