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

И аргументы кажутся разумными: соответствие между объявленными интерфейсами и реализующими их модулями должны быть известны системе и не могут быть известны использующими модулями.

В цепочке "клиент --> сущность --> интерфейс --> реализация" соответствие "интерфейс --> реализация" не известно клиенту и известно системе. Это справедливо и не только для языка Оберон.

Возможность построить модуль для реализации нескольких ранее объявленых интерфейсов тоже заметный плюс.

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

Если так беспокоит проблематика конфигурирования модулей в Обероне, то такая проблема есть, она обсуждалась. Могут быть разные подходы к ее решению. Почему обязательно они должны лежать на уровне того же самого языка реализации? В частности, этот вопрос находится в прямой сфере интересов т.н. кластерно-модульного программирования:
»сообщение 3590«
»сообщение 3128«
»сообщение 3168«
»сообщение 3097«
»сообщение 3114«

Ответ на »сообщение 3935« (AVC)
___________________________
А именно: квалифицирующий импорт видится ему неуместным элементом "сильной" связи там, где должна господствовать "слабая".
Разве не так?..

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

В качестве же Арины Родионовны здесь выступает вовсе не Деннис Ритчи, а Богданов-Малиновский (с примкнувшим к нему Людвигом фон Берталанфи).
Это будет трудная охота; Антон Григорьев даже опасается, что для многих она станет последней... :)
Хорошо... бы...

Ответ на »сообщение 3934« (Сергей Перовский)
___________________________
Хотя ASU и открещивается от COM технологии, его рассуждениям соответствует прежде всего она.
??? А интерфейсы CORBA не примеряли? Вроде бы тоже... соответствуют... Но по секрету, шепотом... скажу... что в этих реализациях интерфейсов... системных «плюшек» очень много...

СОМ технология во многом не совершенна, но этот принцип реализован очень здраво.
Без этого принципа... говорить было бы не о чем...

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

Возможность объектного интерфейса это, конечно, плюс Оберону, но это скорее недоработки СОМ технологии.
(и кто бы еще объяснил этот «объектный интерфейс»)... Если исходить из сути, то... интерфейс не может быть ничем иным, как декларацией... Как же выглядит объектная декларация?.. (и зачем она вообще нужна?)

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

Но тогда становится бессмысленным Ваш вопрос: "Почему Вы утверждаете, что Оберон удобен для системного программирования?" - да про системное программирование в Вашем смысле рассуждения и не велись.

Системный программист такую вольную трактовку термина своей сферы компетенции вряд ли бы дал. :) Значит, речь о специалисте иной квалификации.

Кстати, а с чего мы вдруг решили, что программная система должна подчиняться воззрениям философа-экономиста Богданова-Малиновского и биолога Людвига фон Берталанфи? (Что же мы тогда забыли про Н.И.Бухарина?) Потому что называется "система"? Хорошо. Давайте назовем сие "сооружением" и обратимся в сферу строительного дела. Или там труды упомянутых ученых игнорируют?

Ответ на »сообщение 3933« (AVC)
___________________________
Интерфейс (он же "междумордие" :) ) должен находиться где-то "между".
Но посмотрим внимательно, чьи сущности ("клиента" или "сервера") обыкновенно объявлены в интерфейсе. IMHO, это сущности (типы, константы, переменные, процедуры и т.д.), экспортируемые "сервером".
IMHO, если бы интерфейс что-то говорил о клиенте (я допускаю, что могут быть какие-то особые случаи), то это как раз был бы пример нарушения разделения системы на уровни, о котором Вы говорите. Ведь получается, что "сервер" обладает знанием о "клиенте", т.е. превышает уровень своей компетенции. Это уже не Богданов у нас получается, а Паркинсон. :)
Про обратную связь хотите поговорить?.. Не думаю, что в данном контексте правомочно говорить о клиент-серверной архитектуре, по той простой причине, что использовать сервис и образовывать систему... не одно и то же...

Если брать Си/Си++, то эта задача в них и сейчас не решается.
Иначе попробуйте объяснить наличие стандартного пункта меню (и кнопки тулбара) "Rebuild all".
Зачем это надо, раз все под контролем?
Так я и F9 не сильно... уважаю... Собственно, с этого и началось... :)

>> Меня эти вопросы ничуть не затрудняют. Если позволите, то дам свой ответ: кнопочки находятся на интерфейсной панели телевизора или плиты. Кнопочка – это не горелка, кнопочка – это приспособление для человека (даже если находится на плите или поставляется с плитой). Попробуйте представить себе кнопку в виде иголки или столь тугую, что нормальный человек ее нажать не сможет. Представили? Хорошо... Надеюсь понятно?
А почему именно человек?
Наверное, потому, что на него рассчитывается интерфейс... Но в «роли» человека может выступать кто/что угодно... поддерживающий работу через этот интерфейс. (Об этом здесь уже много сказано).

Может быть, у меня хозяйством занимается робот? :)
Вполне.

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

С системной точки зрения объект низшего уровня именно потому может использоваться в разных контекстах и разными "хозяевами", что (почти) ничего не предполагает об объектах высшего уровня.
слово «(почти)» совершенно излишне, без него Вы, собственно, подтвердили то, о чем я здесь говорю. Но, с Вашего позволения, я усилию это высказывание: объект высшего (над-) уровня тоже не предполагает ничего об объектах нижнего уровня... (включая и подуровни...).

Ответ на »сообщение 3928« (Илья Ермаков)
___________________________
Александр, логика модуля и не включает как таковую межмодульную связь. Межмодульную связь отстраивает компоновщик (в Оберонах – динамический).
О! Золотые слова!!!

По факту, IMPORT A - это не установление связи с реализацией A, это всего лишь импорт некоторого интерфейса (лежашего, кстати, в отдельном файле - .sym), безонтосительно того, что там под этот интерфейс потом подставит загрузчик. Да, в в существующих реализациях Обероне имя импортированного интерфейса совпадает с именем модуля, так сделано для простоты, и в большинстве случаев более сложную схему нетрудно сэмулировать.
Угу... Значит возвращаемся к разговору о том, что ручками все можно сделать?.. Не убедили!..

Но нетрудно представить себе реализацию загрузчика, которой мы можем сказать, что для интерфейса A, используемого некоторым модулем C, нужно подгрузить в качестве реализации модуль AImplV12 или что-нибудь еще.
Мне нетрудно представить и прогулку по Марсу... Что из этого следует?..

Да, исходные тексты не разбиваются на два файла,
А кто об этом говорил? (только не надо показывать пальцем... в мою сторону... ошибетесь) :)

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

Таким образом, когда мы пишем в тексте модуля A.Do, то мы не подразумеваем модуль Do, а подразумеваем всего лишь обращение к некоторому внешнему модулю через интерфейс A. И чем тут плох квалифицированный импорт - это же импорт интерфейсов? Пусть наш модуль взаимодействует с окружающим миром по десятку интерфейсов, так разве не удобно всюду в его исходном тексте видеть, к какому из них он в том или ином случае обращается?
Я уже объяснял это... Понимаете у одного интерфейса может быть много реализаций... Подумайте над этим.

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

Может быть, повоюем против понятия "комплексное число", потому что непонятно, каким образом оно связано со словом "комплекс"? :-)
Очень даже прямая связь...

Прекрасно, никто не возражает против, того что лично Вы под этим понимаете нечто другое, нежели то, что описано в любом энциклопедическом словаре computer-science-направленности.
Но тогда становится бессмысленным Ваш вопрос: "Почему Вы утверждаете, что Оберон удобен для системного программирования?" - да про системное программирование в Вашем смысле рассуждения и не велись.
Понятно... Действительно, Вы правы, если под «системным программированием» понимать все что угодно, то говорить действительно не о чем...

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

А именно: квалифицирующий импорт видится ему неуместным элементом "сильной" связи там, где должна господствовать "слабая".

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

Если в языке используется сторонняя сущность, то у нее должно быть:
1) имя;
2) категория (константа, переменная, тип, процедура);
3) хотя бы приблизительный интерфейс (для процедур).

Берем крайность -- независимую компиляцию на уровне Фортрана (ассемблера).

Чем все это отличается от Delphi (автоматически и от Оберона) применительно к слабым связям?
1. Не указывается источник заимствования (вообще: ни в самом модуле, ни в точке использования).
2. Ослаблен контроль типов и версий (допустим, его просто нет).

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

Значит, остается только источник заимствования. Его отсутствие равносильно наличию одного-единственного источника с фиксированным именем (назовем просто LIBRARY). Проведем параллель с обычным call-центром. Есть некая организация, у которой либо один контактный телефон, либо несколько. В первом случае клиент не задумываясь (слабая связь, логическая коммутация) звонит по единственному номеру и физическая коммутация осуществляется call-центром (Если пользователь выбрал метод расчета, то подгружается соответствующий модуль, происходит привязка конкретной процедуры и... последующий вызов...).

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

Так в чем сомнения?

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


Цитата из »сообщение 3889«:
А одна из заповедей системного проектирования – инкапсулируйте! Оставляйте снаружи только интерфейсы. Да, собственно, это давно уже не новость...

ASU, следуя мэйнстрим-трактовке, не делает различия между инкапсуляцией (encapsulation) и информационным сокрытием (information hiding). А такой взгляд -- более жесткая связь, нежели понимание (и применение) инкапсуляции как средства абстрагирования/комбинирования кода и данных безотносительно контроля области видимости (как это понималось в оригинале -- в CLU). В Обероне есть инкапсуляция как при отсутствии информационного сокрытия, так и вместе с ним -- у программиста есть выбор. Ну а интерфейсы -- через них и работают модули. Это недопонимание? Может, слово "интерфейс" понимается по-разному?

Смотрим »сообщение 3891«:
Мне бы не хотелось, чтобы слово «интерфейс» воспринималось узко, как COM-интерфейсы. Такой взгляд может стать причиной недоразумений. В данном контексте, я говорю о системных интерфейсах. Любая система имеет два или более уровней. Взаимодействие между уровнями происходит посредством объявленных интерфейсов, обязательных для обоих взаимодействующих уровней.

Каково же более широкое понимание интерфейса?
1. Интерфейс сам по себе (ему может соответствовать группа реализаций)?
2. Интерфейс декларирует сущности в минимальном варианте (только имена)?

Такой интерфейс реализуем в Обероне (как впрочем и в других языках), но этот интерфейс не имеет языкового контроля. Если именно это является "неудобством", "неполезностью", "ненеобходимостью" механизма экспорта-импорта в Обероне, то возможно и так. Просто разные взгляды разных людей с разным опытом и разными критериями оценки баланса "гибкость-надежность". (Я не очень большой любитель Си, но у меня даже TASM делал проверку типов... очень строго... между прочим)