Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4186 19-04-2007 08:34 | |
Ответ на »сообщение 4173« (Руслан Богатырев)
___________________________
4. Связь блока с именем_сущности может выполняться как на этапе компиляции (локальные сущности модуля), так и на последующих этапах (любая внешняя сущность).
Поправка. Надо читать так -- 4. Связь блока с именем_сущности выполняется статически, на этапе этапе компиляции (как локальные сущности модуля, так и любые внешние сущности).
Речь идет только о тех сущностях языка Оберон (тип, константа, переменная, процедура), которые вкладываются в главную сущность -- модуль. Модуль не может иметь внутри себя другие модули.
№ 4185 19-04-2007 07:37 | |
Ответ на »сообщение 4181« (ASU)
___________________________
Речь о том, что модуль с модулем связываться вообще не должны, безотносительно механизмов внутри модулей.
В языке Оберон модули (MODULE) не связываются напрямую с модулями. Это не просто категорически запрещено. Это невозможно. Модули соединяются исключительно через переходники под названием "интерфейс" (DEFINITION). Эти переходники могут соответствовать одному модулю (базовый подход), а могут нескольким (вариативность реализаций).
Перекоммутация сущностей возникает как при замене реализации под фиксированный интерфейс (линкующий загрузчик), так и при использовании собственной схемы ретрансляции связей:
1. Через процедурные переменные (ссылки на процедуры)
2. Через процедуры и методы
Динамическое связывание в рамках ООП реализуется в Оберонах как традиционным образом (методы-константы, полиморфизм), так и нетрадиционными способами:
1. методы-переменные (для любого объекта одного и того же класса можно перекоммутировать его методы).
2. расширяемые сообщения (родовая шина сообщений).
Кроме этого, существуют и детально проработаны уже подробно освещавшиеся здесь приемы (инверсия импорта, инсталлируемая точка доступа, инсталлируемые каталоги).
Для сущностей, лежащих за рамками языка (вне его контроля) и отображаемых с некоей выбранной парадигмы (или еще выше -- методологии), может использоваться связывание (коммутация) по любым запрограммированным схемам и протоколам через обращения к процедурам, реализующим соответствующее отображение. В частности, подобным образом реализуется метапрограммирование, лежащее в Оберонах вне сферы языкового контроля, но с доступом к run-time.
Что касается надмодульных понятий: супермодуль=кластер, то этот вопрос уже подвергался освещению.
Он находится в прямой сфере интересов т.н. кластерно-модульного программирования:
»сообщение 3590«
»сообщение 3128«
»сообщение 3168«
»сообщение 3097«
»сообщение 3114«
№ 4184 19-04-2007 07:03 | |
Ответ на »сообщение 4181« (ASU)
___________________________
Неважно. Вопрос был о другом... Речь о том, что модуль с модулем связываться вообще не должны, безотносительно механизмов внутри модулей.
Вы хотите иметь сущьность более высокого уровня чем модули?
Назавём, например, СуперМодуль.
При этом выстраивается иерархия процедуруы, переменные, объекты объденяются в модули, с соответствующим интерфесом, а сами модули в СуперМодули, которые имеют свои интерфейсы?
№ 4183 19-04-2007 06:50 | |
Ответ на »сообщение 4165« (Stargazer)
___________________________
Ответ на »сообщение 4163« (al_mt)
___________________________
Вы будете смеяться, но мне довелось заниматься системой, для которой, мы сделали возможность "на горячую" перетыкать модули БД. Локальная/сетевая/никакой.
В случае "никакой" система сохраняла возможность работать с локальными файлами в XML. В принципе можно было сделать и автоматику, типа отваливается сетевая БД, клиент прозрачно переключается на локальную, даже не заметив этого :)))))))))
Охотно верю. Я сам подумывал о таком, но представив себе проблемы транзакций и последующей синхронизации в реал-тайм системе, вовремя отказался :)
Смысл-то несколько в другом, как мне кажется. Если можно любую подсистему отключить, и при этом система не перестанет быть "системой", тогда зачем называть эту подсистему "системообразующей"? Отрубили сервер, и централизованная система распалась на ряд кластеров. Это уже другая "система", согласитесь.
Выдернуть "системообразующий" модуль невозможно даже из "ресурсного" ПО :)
Если подходит с такой меркой к вышеприведённой задаче, то "системообразующим" будет класс, который как раз и занят "разбором полётов" кто из БД в данный момент рабочий. Всё достаточно естественно (хотя не сказал бы, что просто :)) реализуется в ООП, но с трудом представляю, как это вменяемо сделать без оного :(
№ 4182 19-04-2007 06:46 | |
>>> На этой позитивной ноте и завершим разговор.
Ну вот так "ничего нового не сказал"! Просто не верю своим глазам!
Мирное завершение дискуссии о семантическом моделировании - это самое новое и есть.
№ 4181 19-04-2007 06:40 | |
Ответ на »сообщение 4180« (MS)
___________________________
Это к вопросу о вагончиках и рельсах.
Модуль является единой сущьностью и объявленный интерфейс является его представительством (объявлением контракта) во внешний мир. Как он его будет выполнять, в общем случае, Вы незнаете.
Это все понятно...
Может при обращению к модулю вы попадёте в диспетчер, который по своим правилам создаст связь с некой сущьностью - объектом, константой, может даже и процедурой.
Неважно. Вопрос был о другом... Речь о том, что модуль с модулем связываться вообще не должны, безотносительно механизмов внутри модулей.
(Давайте не будем начинать все сначала, если ко мне есть вопросы, то напишите и отправьте по e-mail, я постараюсь ответить)
№ 4180 19-04-2007 05:54 | |
Ответ на »сообщение 4178« (ASU)
___________________________
Ответ на »сообщение 4174« (MS)
___________________________
>> Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...
> Нет, не может. Порядок доступа определятся модулем.
Может быть проголосуете? А то один одно говорит, другой - другое... Кому же верить?.. :)))
(Вы видимо невнимательно прочитали вопрос)
Это к вопросу о вагончиках и рельсах.
Модуль является единой сущьностью и объявленный интерфейс является его представительством (объявлением контракта) во внешний мир. Как он его будет выполнять, в общем случае, Вы незнаете.
Может при обращению к модулю вы попадёте в диспетчер, который по своим правилам создаст связь с некой сущьностью - объектом, константой, может даже и процедурой.
№ 4179 19-04-2007 05:17 | |
Ответ на »сообщение 4175« (Илья Ермаков)
___________________________
Подумать над этим стоит.
Ну, вот и славненько... На этой позитивной ноте и завершим разговор.
№ 4178 19-04-2007 04:58 | |
Ответ на »сообщение 4174« (MS)
___________________________
>> Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...
> Нет, не может. Порядок доступа определятся модулем.
Может быть проголосуете? А то один одно говорит, другой - другое... Кому же верить?.. :)))
(Вы видимо невнимательно прочитали вопрос)
№ 4177 19-04-2007 04:55 | |
Ответ на »сообщение 4170« (info21)
___________________________
Хм.. Это называется "сформулирована"?..
С тех пор я ничего нового не сказал... можете сами сравнить...
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|