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

Ответ на »сообщение 2547« (Илья Ермаков)
___________________________
Вопрос: можно ли в КП/BlackBox выделить такое подмножество (вроде Си-подмножества в C++; как языка, так и внеязыковых средств, включая библиотеки), которые позволили бы осуществить относительно простую миграцию полностью или частично наработанных решений в другие Обероны или даже другие языковые платформы? Чем-то это может напоминать кросс-программирование (когда на целевой платформе иметь инструментарий нереально или дорого, а проще все создавать для нее на другой). Вот это обсуждать и даже реализовывать, на мой взгляд, было бы интересно и, что самое главное, полезно в практическом плане (да и в плане выживания Оберонов).

Мне кажется, нужно работать немного в другом направлении - во-первых, можно подумать об автоматических эквивалентных преобразованиях программ на основе метаинформации. Для Оберонов необходим единый стандарт на библиотеку метапрограммирования - это станет основой для любого взаимодействия, в том числе распределенного. Полезно также подумать о стандартизации расширения компиляторов псевдомодулями. И, опять же, о стандартной библиотеке доступа к синтаксической структуре программы - это нужно для всех предыдущих задач (+ на основе такой библиотеки легко реализовывать всякие intellisense и проч., которых так многим не хватает...). Образцом может стать ASIS - Ada Symbolyc Information System. Нам нужен свой OSIS.

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

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

Просто в качестве рефлексии: здесь к модулям применен тот же прием (инсталляция коммутирующего объекта), что и в О-1 к записям.

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

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

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

Я вижу как минимум две непосредственные области применения.
Фабричные объекты-каталоги (как в ББ) и состояния.
В известном паттерне GoF состояния рассматриваются как синглетоны, т.е. для каждого создается класс (хотя он не имеет собственных данных). А ведь на деле, как правило, достаточно процедуры (и процедурной переменной в объекте, меняющем состояния). В качестве примера опять-таки сошлюсь на свое глупое решение с порождением класса для каждого отдельного действия. Немного утешает, что здесь я не один, а в теплой компании GoF. :)

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