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

Главное. "Слабые" связи тоже требуют определенного механизма.
В Обероне такой механизм есть.
Он Вам не нравится.
Но взамен Вы предлагаете некий неопределенный механизм, с передачей всей ответственности системному загрузчику.
Остаются неясными:
1) механизм межмодульного контроля типов (этим отличается раздельная компиляция от независимой);
2) механизм разрешения конфликта имен.

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

Речь о том, что прикладной программист не должен знать, что и откуда будет импортироваться и куда экспортироваться. Он не должен(!) на уровне модуля прописывать системную логику, те самые «слабые» связи. «Слабые» связи не должны быть компетенцией языка разработки. Это задача системного линкера при статическом связывании или системного загрузчика при динамическом связывании.

Мы уже выяснили, что в Обероне ни список импорта, ни квалифицирующий импорт в принципе не препятствуют тому, чтобы "слабые" связи были перекоммутированы "на лету".

А что предлагаете Вы?
Не указывать, какие модули импортируются и не квалифицировать импортируемые идентификаторы в надежде на системный загрузчик?
Он Вам "налинкует", ага... :) Вы просто получите кучу ошибок в итоге.
В свое время мы разбирали, что одна из функций модуля -- определить пространство имен.
Причем само пространство имен (без модульности) не гарантирует от ошибок (рассматривался, в частности, учебный пример Свердлова на C#).

Другой момент. Вы предлагаете предоставить "слабые" связи системному загрузчику (при динамическом связывании).
Вопрос на засыпку: а как компилятор будет осуществлять межмодульный контроль типов до того как в дело вступит системный загрузчик?

Ответ на »сообщение 3870« (Илья Ермаков)
___________________________
Все верно, в Оберонах большая часть межмодульных связей и декларируется в терминах интерфейсов.
«Часть»?.. Хорошо сказано... возможно по поводу строгого аскетизма и правильности...

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

Другие связи выстраиваются динамически на основе разъемов. И разновидностей таких разъемов весьма много.
Здорово!..

И описываются эти разъемы как раз-таки в терминах интерфейсов (абстрактные записи).
Замечательно!!! (не подумайте, в моих словах нет иронии... пока).

В модульных не-ОО языках (Модула, старая Ада) такие разъемы могли быть только процедурными (обычный callback).
В ОО-модульных языках появляются объектные разъемы.
Хм... Разъемы – это интерфейсы? Я правильно Вас понимаю? Что означает процедурный или объектный интерфейс?.. Любая сущность (модуль, в том числе) применяются тогда, когда они полезны, то есть, обладают некими возможностями, которые необходимы и, при этом, могут предъявлять свои потребности, которые необходимо удовлетворить. Возможности и потребности – это декларация... Любому, кто использует интерфейс безразлична его реализация (тем более, что она может меняться... сегодня через USB пишем на флэш, завтра на жесткий диск, а послезавтра... интерфейс остался неизменным, а его потребители с обоих сторон могут меняться без потери работоспособности системы).

Эти разъемы могут использоваться по разным схемам.
1) Объектный callback-разъем.
Хм... Это о чем?.. Callback – это обратный вызов, это будильник, который меня будит...

2) Разъем подключения реализации (в Блэкбоксе называется Hook).
Вы отстаиваете полезность квалифицируемого импорта на уровне языка или среды?..

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

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

4) Инсталлируемые каталоги. "Лицевой" модуль сервиса определяет абстрактные интерфейсы для этого сервиса и предоставляет инсталлируемую точку доступа к фабрике объектов, реализующих эти интерфейсы. Модули реализации динамически инсталлируют фабрики в "лицевые" модули.
«Фабрика» – это элемент языка Оберон или RTL?

Замечу, что во всех этих схемах ООП является служебным механизмам, а не системообразующей схемой. В частности, не используется наследование реализации.
Это предмет гордости?.. С моей точки зрения... это серьезный минус... Любые системы, а открытые, тем более, имеют свою логику развития. И ООП удобный механизм реализации такого развития.

И, наконец, нужно упомянуть особый способ динамической коммутации модулей - через механизмы метапрограммирования.
Макроязык внутри Оберон?..

В частности, процедурные разъемы в исходной форме (как указатели на процедуру) в Блэкбоксе используются редко, чаще прибегают к символьной ссылке на процедуру (ведь модуль, к котором находится процедура, может быть перезагружен, и адрес процедуры изменится).
Илья, меня не интересуют реализации. Поверьте, я не первый год занимаюсь разработкой систем, и сам могу сделать любую необходимую мне реализацию. Здесь отстаивалась мысль, что квалифицированный импорт, который имеет место быть в языке Оберон, - это очень правильное, надежное и удобное решение. У меня есть сомнения относительно того, что подобные вещи в любом языке
а) необходимы;
б) полезны;
в) удобны.
Но не вижу смысла говорить в терминах: «нравится» или «не нравится». Ранее неоднократно утверждалось, что Оберон – хороший язык системного программирования. Покажите это на данном конкретном примере.

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

Здесь я удивлен... Нет, не тем, что «заклевали» (на форумах это обычное дело), а тем, что вы («оберонщики»)... считаете это важным. Мне пространно «ответили» Илья и Руслан, но... ответа так и не прозвучало...

Вообще-то знакомое выражение. Когда некий корреспондент задает вопрос интервьюируемому и получает некий ответ, то он нередко восклицает: "Ответа я не получил!" Да неужели? Ответ был представлен. Вот только ответ (форма, содержание) может не устраивать вопрошающего по тем или иным причинам.

Чтобы не было ненужной спекуляции (и выяснения причин недовольства), к которой, как я понимаю, дело потихоньку движется, а также во избежание недопонимания я предлагаю очень простой вариант: многоуважаемый ASU вкратце объясняет свое понимание системности, квалифицирующего импорта, сильных и слабых связей применительно к языку Delphi (надеюсь, это не вызовет больших затруднений). Если есть проблемы с Delphi -- любой иной язык по выбору ASU.

Т.е. предлагаю вернуться к инициирующему »сообщение 3856« и подставить вместо Оберон другой "параметр". Мне бы того же хотелось... Может быть подскажите, как квалифицированный импорт сочетается с "системностью" Oberon?

После этого можно будет разобрать отличия/специфику Оберонов в данном контексте.

Ответ на »сообщение 3874« (AVC)
___________________________
В программировании "сильные" и "слабые" связи как раз и находят свое выражение в модульности.
а) не только в модульности;
б) модульность обязана реализовывать «слабые» связи (т.е. я бы усилил Ваше высказывание).

Главное, это прямо соответствует принципам системного подхода.
Это выражение одного из основополагающих принципов системного подхода.

Слава Богу, хоть кто-то понимает эту потребность!
:)))

А то нас, бедных оберонщиков, прямо заклевали за то, что мы считаем это важным.
Здесь я удивлен... Нет, не тем, что «заклевали» (на форумах это обычное дело), а тем, что вы («оберонщики»)... считаете это важным. Мне пространно «ответили» Илья и Руслан, но... ответа так и не прозвучало...

По сути предлагаемых Обероном механизмов.
В Обероне экспорт модуля может использоваться как место коммутации.
Очень хорошо!..

Модуль экспортирует "гнездо" коммутации (процедурную переменную, указатель на фабричный объект и т.д.), система может "на лету" подключить туда ту или иную реализацию функциональности, загрузив дополнительный настроечный, "теневой" :) модуль, явно не импортируемый другими модулями. Благодаря такой организации, этот модуль может быть заменен на другой, после чего его можно даже просто выгрузить.
Замечательно!..

Возможно, обероновские механизмы модульности здесь несовершенны и могут быть улучшены.
Но они все же позволяют решать данную задачу, при сохранении простоты языка и программной архитектуры.
Хм... Простите за настойчивость, но... где же решение?.. Да, я согласен с тем, что в Обероне есть хорошие механизмы, но речь не о них. Речь о том, что прикладной программист не должен знать, что и откуда будет импортироваться и куда экспортироваться. Он не должен(!) на уровне модуля прописывать системную логику, те самые «слабые» связи. «Слабые» связи не должны быть компетенцией языка разработки. Это задача системного линкера при статическом связывании или системного загрузчика при динамическом связывании. Термин «системный», в данном случае, не означает принадлежности к ОС, но к любой, в том числе, и вновь создаваемой системе. Так почему Оберон предусматривает квалифицируемый импорт, а «оберонщики» столь настойчиво доказывают его необходимость и полезность? Мой вопрос был об этом.

Ответ на »сообщение 3858« (Руслан Богатырев)
___________________________
>>>Хотелось бы понять, сколь это важно для языка.
Это упрощает синтаксис, а "соглашение по именованию" – побочный эффект

Немного информации на тему "квалифицирующий импорт".

Вот цитата из совершенно необероновского курса "Основы объектно-ориентированного проектирования":

Всякое общение двух модулей A и B между собой должно быть очевидным и отражаться в тексте A и/или B.

http://www.intuit.ru/department/se/oopbases/3/8.html

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

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

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

>>>Единственный случай, где наследование реализации используется - это framework с базовыми типами-заготовками, поведение которых можно расширять через наследование...

Действительно, типы-заготовки ("полуабстрактные" типы) часто встречаются во фреймворке.
Но все же это не единственное место, где они могут встречаться.
Как мне кажется, главная причина использования полуабстрактных типов (классов) -- необходимость введения системы взаимодействующих (двух и более) типов и упрятывания организации их взаимодействия от типов-наследников.
Такими взаимодействующими типами могут быть, например, контейнер и итератор, и т.д.
IMHO, именно на этот случай Шиперски сформулировал свой принцип "No Paranoia".