Ответ на »сообщение 4199« (AVC)
___________________________
>> Вопрос "где?" я не понял...
> Если Вы не ограничиваетесь базовыми типами (целыми, вещественными, символьными и т.д.), то должны где-то объявить новые (структурированные, абстрактные и т.п.) типы.
Меня интересует: где и как они объявляются? как скрываются детали их объявления?
Спасибо за уточнение, теперь понятно.
Давайте разбираться. Рассмотрим попарно (смежные) уровни системы. "Пространство" между уровнями доступно каждому из смежных уровней и образует нечто вроде "области видимости". Все (включая типы данных, шаблоны, сервис и пр.), что объявлено в этом "пространстве" могут использовать элементы обоих уровней.
Система может включать в себя более двух уровней. В этом случае на систему ложится задача поддерживать в согласованном состоянии описания, которые проецируются более, чем на одно межуровневое пространство. Это достигается посредством проекции или поддержанием копий описаний на каждом из уровней. Таких общесистемных описаний, как правило, немного, но они есть.
(Но лучше бы это обсуждать вне Oberon).

Например, одной из функций обероновских модулей является определение (абстрактных) типов данных. При этом детали определения типа, относящиеся к реализации (а не к интерфейсу), скрываются в модуле (не экспортируются), т.к. модуль задает "границы видимости".
То есть, поддерживается инкапсуляция, как то и требуется в современной парадигме модульного программирования... Это хорошо.

Ответ на »сообщение 4201« (AVC)
___________________________
>>>В смысле -- "веселящего газа"? :)
Не совсем.

  - Если это азот, то он на букву "А", а я умею делать только на букву "Н".
  - Но по-латыни это называется нитрогениум.
  - Дорогой мой, - сказала машина, - если б я умела делать все на  "Н" на  всевозможных языках, то я была бы Машина, Которая Может Делать Все В Пределах Всего Алфавита, потому что любая вещь на каком-либо из языков наверняка начинается на "Н". Дело обстоит не так хорошо. Я не могу сделать больше, чем ты придумал. Азота не будет.

Ответ на »сообщение 4202« (Stargazer)
___________________________
"Какое-то время" - конкретно, какое?
Не знаю, это определяется пользователями и их задачами. Если у них без системы, скажем, счета из сбыта в финансы передавались раз в день... то значит день они могут жить без связи между подсистемами... И так по каждой группе пользователей и их задачам...

Интересует, когда наступит "упор" (и наступит ли вообще) и вся система остановится.
"Система" не остановится... Система просто исчезает (на какое-то время), остаются отдельные подсистемы.

Ответ на »сообщение 4189« (Как слышно? Приём!)
___________________________

...
Возможность манипулирования активным документом со вложенным вьюером впечатляюща...

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


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

Это я так.. Навеяло :) Согласно религиозным традициям текст обязан быть двусмысленным.

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

...
Если по каким-то причинам одна из функциональных подсистем недоступна, то остальные подсистемы продолжают работать, обслуживать пользователей и обмениваться информацией между собой. После восстановления связи с «недоступной» подсистемой происходит автоматическое включение ее в работу. Если недоступной становится одна из системообразующих подсистем, то прекращается обмен информацией между подсистемами, но при этом сами подсистемы в состоянии какое-то время продолжать обслуживать пользователей. После восстановления подсистемы информация всех функциональных подсистем будет автоматически синхронизирована.

"Какое-то время" - конкретно, какое? Интересует, когда наступит "упор" (и наступит ли вообще) и вся система остановится. Если не остановится, тогда связи между подсистемами можно считать чисто условными, а системы как таковой нет. Вернее, она есть, но только в голове у архитектора.

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

Ответ на »сообщение 4146« (AVC)
___________________________
>>>>>>Болото болтовни.
>>>Заходите -- поквакаем. :)
А смысл? Ведь сразу было ясно: Азота не будет!

В смысле -- "веселящего газа"? :)

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

«Если разработчик пишет модуль, то он может написать из этого модуля обращение к другому модулю?»

Нет, не может. Он обращается к интерфейсу, имя которого соответствует имени его реализации (модуля).

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

Под один и тот же интерфейс можно иметь множество реализаций (что на практике при разработке сложных систем и делают). Подмена (коммутация) реализации может происходить на любом этапе, начиная с линковки.

Компилятору по барабану, что есть в реализации (внешнего, импортируемого) интерфейса. Он не лезет туда за информацией (в этом суть раздельной компиляции). Вся информация собрана в бинарном (оттранслированном) варианте интерфейса (который называют символьным файлом, SYM-файл). Технология формирования SYM-файлов очень подробно рассмотрена и опубликована в работах ETH Zurich.

Компилятор гарантирует, что реализация выполнена в строгом соответствии с интерфейсом (полностью согласуется с ним), включая строгий контроль типов, а также контроль версионности (как на уровне интерфейса в целом, так и для каждой описанной в нем сущности -- это сделано в ETH-реализациях Оберона).

Версионность зашивается в SYM-файл (уникальная метка, fingerprint) и может контролироваться вплоть до даты и времени компиляции (даже безотносительно реальных изменений интерфейса). При компиляции любых модулей (MODULE) в объектные файлы зашивается уникальная контрольная метка (либо всего интерфейса, либо даже каждой сущности). Если потом будет сделана попытка собрать (подстыковать) к интерфейсу модули, не соответствующие уникальной метке -- это тут же будет обнаружено (реакция может быть реализована любая). Аналогично и в случае импорта сущностей (если один модуль импортирует из какого-то интерфейса сущность, а другой тоже зависит от этого интерфейса по отношению импорта, но метки разные, то рассогласование будет обнаружено).

В Обероне вся работа строится через интерфейсы по одной простой причине. Модуль -- это прежде всего средство абстрагирования (а не коробок со спичками-сущностями). У него есть две части -- интерфейс и реализация, при этом в отличие от других языков, реализация "плавает" (может подменяться), но со строгим контролем соответствия интерфейсу, который для компилятора всегда остается первичным. То, что в Обероне Вирт сделал "свертку" схемы Модулы-2, повлияло лишь на работу (понимание) программиста. Для компилятора схема не изменилась. Все также DEFINITON (первичный) и MODULE (вторичный, подменяемый). Схема модулей Оберона заточена прежде всего под индивидуалов (подчеркиваю, индивидуалов), программиста-хозяина (по Ершову).  Сам ставлю задачу, сам проектирую, сам реализую (возможно, коллега чуток помогает). Это кустарное производство. Для промышленного производства (а сложные, сурьезные системы группой из одного-двух лиц, вообще говоря, не делаются) требуется разделение труда и отчуждение спецификации (воплощаемой, в том числе, в интерфейсе) от исполнителя. Это программист-слуга. Я уже показывал, как без изменения языка и с минимальными правками в инструментальной среде обеспечить промышленный потенциал Оберонов.

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

Если интересует вопрос отображения той или иной методологии на тот или иной язык реализации (программирования), то сначала эту методологию надо сформулировать, затем расписать подробно всю "законодательную базу" сущностей и отношений для каждого (подчеркиваю, каждого) охватываемого ею этапа (будет ли там отдельно макетирование/прототипирование, не будет; аналогично для моделирования, проектирования и т.п.). Затем выстроить всю схему отображений сущностей (с этапа на этап, с одного представления на другое) с указанием способов контроля отображений (если следующий этап вносит свои коррективы, то это должно четко согласовываться с требованиями предыдущего, с которого ведется отображение сущностей и связей).

Рассуждать вообще и идти со стороны языка Оберону (это даже еще не инженерные вопросы, не говоря уже об архитектуре) в "открытый космос" под названием "общая теория систем" в Вашей творческой интерпретации -- это IMHO просто приятное времяпрепровождение. Большого толку от этого самой аудитории не будет. Хотя Вы лично для себя извлечете немало рационально-полезного.

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

б) типы обязаны быть, в интерфейсах, в том числе.
Вопрос "где?" я не понял...

Если Вы не ограничиваетесь базовыми типами (целыми, вещественными, символьными и т.д.), то должны где-то объявить новые (структурированные, абстрактные и т.п.) типы.
Меня интересует: где и как они объявляются? как скрываются детали их объявления?
Например, одной из функций обероновских модулей является определение (абстрактных) типов данных. При этом детали определения типа, относящиеся к реализации (а не к интерфейсу), скрываются в модуле (не экспортируются), т.к. модуль задает "границы видимости".

Ответ на »сообщение 4146« (AVC)
___________________________
>>>>>>Болото болтовни.

>>>Заходите -- поквакаем. :)

А смысл? Ведь сразу было ясно: Азота не будет!

Ответ на »сообщение 4191« (info21)
___________________________
>> Тогда у меня остался только один вопрос: «Почему адепты Oberon в одном случае отстаивают простоту и строгость, а в другом аналогичном случае – сложность и халатность? Когда же им верить?»...
> Поклеп и провокация.
Ха-ха-ха-ха...