Ответ на »сообщение 4034« (Сергей Перовский)
___________________________

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

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

Видятся следующие варианты соответствия "один интерфейс -- несколько реализаций":
1. Эволюция версий (динамика разработки)
2. Разные варианты с учетом доп. конкретизации (платформа, ресурсы, схемы оптимизации и т.п.)

Эти варианты безотносительно статического/динамического воплощения связи (может быть и так, и так).

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

Чтобы не надо было менять ни строчки в каждом импортирующем модуле в описанном Вами случае, надо все версии реализаций (варианты 1 и 2) называть одинаково (поскольку реализуют один заранее заданный и высочайше утвержденный интерфейс), а хранить их порознь (в разных файлах, в разных каталогах, в разных зонах одного документа, различаемых компилятором и т.п.).

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

Ответ на »сообщение 4034« (Сергей Перовский)
___________________________

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

Все это многократно обсуждалось.
Соответствующие понятия "коммутация", "инсталляция" и т.д. разъяснялись не раз Русланом и Ильей.
Сейчас я просто прошу Вас задуматься над фактом, что в Обероне на самом деле можно поменять на лету модуль, обеспечивающий ту или иную функциональность.

Ответ на »сообщение 4027« (Руслан Богатырев)
___________________________
>>>в Обероне квалифицируется интерфейс (DEFINITION)
Мы только что договорились, что это разные вещи :)
DEFINITION - часть модуля, значит мы намертво пристыковываемся к модулю.
Если нужно заменить модуль на другой (естественно с другим именем), то придется менять хотя бы одну строчку в каждом импортирующем модуле.
А как же насчет "без перетрансляции"?
Вынесение таблицы синонимов (по сути таблицы интерфейс - модуль реализации) из модуля в отдельную сущность заметно увеличило бы гибкость межмодульных отношений.

Ответ на »сообщение 4026« (Сергей Перовский)
___________________________

>>>В русском языке термин "системное программирование" произошел не от филосовского или научного понятия "система", а от конкретного (и не очень удачного) термина "операционная система". Так уж получилось.

Применительно к Оберону -- не так уж неудачно. :)
В Оберон-системе любой модуль есть расширение операционной системы.

Ответ на »сообщение 4028« (Илья Ермаков)
___________________________
>>>Можно позаимствовать что-то из Ады
Собственно, про это и звук :)
Писать заглушку, а потом ее подменять, не слишком хороший стиль.
Возможность независимого описания интерфейсов и наследования интерфейсов очень хорошая возможность.

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

Ответ на »сообщение 3995« (Илья Ермаков)
___________________________
Хм... В смысле "селекторы"?
В смысле DevSelectors. ;-) Я о них тут как-то писал уже.

Елки-палки... Сколько работаю - не знал про эту штуку. Модуль-то недокументированный. А как ими пользоваться?
Давайте перейдем на наш форум, чтобы не захламлять ветку:
http://forum.oberoncore.ru/viewtopic.php?p=4410#4410

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

Хм... В смысле "селекторы"?
В смысле DevSelectors. ;-) Я о них тут как-то писал уже.

Ответ на »сообщение 4024« (Сергей Перовский)
___________________________

Вы именуете эти стандарты протоколами, но термин интерфейс гораздо точнее отражает их смысл.

Похоже, Вы меня неправильно поняли (либо я выразился недостаточно понятно). В »сообщение 3996« я говорил о различиях между интерфейсами и протоколами, поскольку ASU поставил их на одну доску. Что касается Оберона, то у него есть спецификации модуля (DEFINITION), которые можно называть интерфейсами модуля (а не интерфейсами системы, ее уровней/слоев). Это спецификация "точек" установления взаимодействия модуля с модулем (сущностей одного модуля с сущностями другого), т.е. интерфейс между модулями.

Что касается протоколов, то в классическом Обероне они в явном виде на уровне спецификаций не поддерживаются. Вообще. Это не есть хорошо (с определенной точки зрения). Но это так.

Ответ на »сообщение 4024« (Сергей Перовский)
___________________________

Ответ на »сообщение 4019« (Руслан Богатырев)
___________________________
Отлично, избавились от терминологической путаницы. Теперь давайте определимся снова, имя ЧЕГО должно использоваться для квалификации импорта?
ASU считает, что это должно быть имя интерфейса, а не модуля, так получается гораздо  более гибко. Присоединяюсь.

В квалификации импорта указывается имя интерфейса. Просто в базисном случае имя модуля совпадает с именем интерфейса (именно имя модуля с именем интерфейса, а не наоборот) и интерфейс строится автоматически.
"Более гибко" - пожалуйста, можно думать о расширении этой схемы, это ВООБЩЕ НИКАК не фиксируется в языке. Это фиксируется в среде/рантайме.
Поскольку именно эта часть Оберонов сейчас активно развивается - пожалуйста, давайте высказывать предложения и идеи и обсуждать.
Можно подумать о способах множественной загрузки модулей, можно подумать о более строгом механизме создания/хранения/обработки спецификаций модулей. Можно позаимствовать что-то из Ады (например, ASIS). Если вы думаете, что "оберонщики все это отметают", то ничего подобного. У нас в планах на развитие ББ все это стоит на очереди. Но очередь имеет более и менее приоритетные задачи.

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

Ответ на »сообщение 4024« (Сергей Перовский)
___________________________

Отлично, избавились от терминологической путаницы. Теперь давайте определимся снова, имя ЧЕГО должно использоваться для квалификации импорта?
ASU считает, что это должно быть имя интерфейса, а не модуля, так получается гораздо  более гибко. Присоединяюсь.

Сергей, скажите пожалуйста, в какой раз мне нужно объяснять, что в Обероне квалифицируется интерфейс (DEFINITION) модуля? Мне нужно перечислить номера сообщений, где об этом четко говорилось?


Не надо так резко. Проблема на самом деле существует.
Оберон предполагает автоматическую сборку описания интерфейса по ГОТОВОЙ РЕАЛИЗАЦИИ - только звездочки поставить.
Тогда как описание интерфейса должно предшествовать разработке модуля.

Этот вопрос я достаточно подробно разбирал при обсуждении идеи верификатора. Это было 10 апреля. См. »сообщение 3788« и %3789

Сообщение ASU, инициировавшее данную дискуссию, датируется 13 апреля и имеет номер »сообщение 3856«.

Мне надо что-то говорить о причинно-следственной связи или это излишне?